Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #47805 > unrolled thread
| Started by | Daniel <danielaparker@gmail.com> |
|---|---|
| First post | 2017-01-03 09:13 -0800 |
| Last post | 2017-01-05 20:22 +0000 |
| Articles | 10 — 7 participants |
Back to article view | Back to comp.lang.c++
Suggestions for a unit test framework Daniel <danielaparker@gmail.com> - 2017-01-03 09:13 -0800
Re: Suggestions for a unit test framework Cholo Lennon <chololennon@hotmail.com> - 2017-01-03 15:36 -0300
Re: Suggestions for a unit test framework Daniel <danielaparker@gmail.com> - 2017-01-05 07:31 -0800
Re: Suggestions for a unit test framework Wouter van Ooijen <wouter@voti.nl> - 2017-01-03 19:41 +0100
Re: Suggestions for a unit test framework Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 17:02 +0000
Re: Suggestions for a unit test framework Ian Collins <ian-news@hotmail.com> - 2017-01-05 08:37 +1300
Re: Suggestions for a unit test framework Dombo <dombo@disposable.invalid> - 2017-01-04 21:34 +0100
Re: Suggestions for a unit test framework Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-05 08:49 +0000
Re: Suggestions for a unit test framework Ian Collins <ian-news@hotmail.com> - 2017-01-05 22:12 +1300
Re: Suggestions for a unit test framework legalize+jeeves@mail.xmission.com (Richard) - 2017-01-05 20:22 +0000
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2017-01-03 09:13 -0800 |
| Subject | Suggestions for a unit test framework |
| Message-ID | <a0695cca-5351-4a98-8549-576f399fc2d7@googlegroups.com> |
I'm currently using the boost unit test framework for a project that doesn't otherwise depend on boost. The features that I'm using are BOOST_REQUIRE, BOOST_CHECK, BOOST_REQUIRE_EXCEPTION, BOOST_CHECK_EXCEPTION, and checking that there are no memory leaks. It's proving too difficult if not impossible to set up continuous integration builds for all the environments and compilers supported that link to boost, so I'm looking for a self-contained replacement that can be included in the distribution. I looked at Catch https://github.com/philsquared/Catch, but it tries to be too clever, resulting in too many issues. Any suggestions? Thanks, Daniel
[toc] | [next] | [standalone]
| From | Cholo Lennon <chololennon@hotmail.com> |
|---|---|
| Date | 2017-01-03 15:36 -0300 |
| Message-ID | <o4gqvg$voo$2@gioia.aioe.org> |
| In reply to | #47805 |
On 01/03/2017 02:13 PM, Daniel wrote: > I'm currently using the boost unit test framework for a project that doesn't otherwise depend on boost. > The features that I'm using are BOOST_REQUIRE, BOOST_CHECK, BOOST_REQUIRE_EXCEPTION, > BOOST_CHECK_EXCEPTION, and checking that there are no memory leaks. > > It's proving too difficult if not impossible to set up continuous integration builds for all the > environments and compilers supported that link to boost, so I'm looking for a self-contained > replacement that can be included in the distribution. I looked at Catch > https://github.com/philsquared/Catch, but it tries to be too clever, resulting in too many issues. > > Any suggestions? > Boost.Test can be used without compiling it and as a subset of the whole Boost (check http://www.boost.org/doc/libs/1_63_0/tools/bcp/doc/html/index.html). I'm using it with Gcc (multiple versions) and VC++ on Linux/Solaris/Windows without a single problem. Regards -- Cholo Lennon Bs.As. ARG
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2017-01-05 07:31 -0800 |
| Message-ID | <cf2398ca-1080-4a86-aa28-42d133b544bc@googlegroups.com> |
| In reply to | #47806 |
On Tuesday, January 3, 2017 at 1:36:43 PM UTC-5, Cholo Lennon wrote: > > Boost.Test can be used without compiling it and as a subset of the whole > Boost Thanks, I'll look into that. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Wouter van Ooijen <wouter@voti.nl> |
|---|---|
| Date | 2017-01-03 19:41 +0100 |
| Message-ID | <586bf06e$0$2851$e4fe514c@newszilla.xs4all.nl> |
| In reply to | #47805 |
Op 03-Jan-17 om 6:13 PM schreef Daniel: > I'm currently using the boost unit test framework for a project that doesn't otherwise depend on boost. The features that I'm using are BOOST_REQUIRE, BOOST_CHECK, BOOST_REQUIRE_EXCEPTION, BOOST_CHECK_EXCEPTION, and checking that there are no memory leaks. > > It's proving too difficult if not impossible to set up continuous integration builds for all the environments and compilers supported that link to boost, so I'm looking for a self-contained replacement that can be included in the distribution. I looked at Catch https://github.com/philsquared/Catch, but it tries to be too clever, resulting in too many issues. > > Any suggestions? google test? catch? Wouter "Objects? No Thanks!" van Ooijen
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-01-04 17:02 +0000 |
| Message-ID | <slrno6qam0.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #47805 |
On Tue, 2017-01-03, Daniel wrote: > I'm currently using the boost unit test framework for a project that > doesn't otherwise depend on boost. The features that I'm using are > BOOST_REQUIRE, BOOST_CHECK, BOOST_REQUIRE_EXCEPTION, > BOOST_CHECK_EXCEPTION, and checking that there are no memory leaks. > > It's proving too difficult if not impossible to set up continuous > integration builds for all the environments and compilers supported > that link to boost, so I'm looking for a self-contained replacement > that can be included in the distribution. I looked at Catch > https://github.com/philsquared/Catch, but it tries to be too clever, > resulting in too many issues. > > Any suggestions? I'm always willing to plug my own: https://github.com/kjgrahn/orchis But it's very minimal, and you can tell I don't like the official unit test ideology very much. I've used Google Test too, but I'm not very impressed. I remember them making it hard to integrate with the build system, unless you choose the build system /they/ like. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-05 08:37 +1300 |
| Message-ID | <ed5172FccfvU5@mid.individual.net> |
| In reply to | #47823 |
On 01/ 5/17 06:02 AM, Jorgen Grahn wrote: > On Tue, 2017-01-03, Daniel wrote: >> I'm currently using the boost unit test framework for a project that >> doesn't otherwise depend on boost. The features that I'm using are >> BOOST_REQUIRE, BOOST_CHECK, BOOST_REQUIRE_EXCEPTION, >> BOOST_CHECK_EXCEPTION, and checking that there are no memory leaks. >> >> It's proving too difficult if not impossible to set up continuous >> integration builds for all the environments and compilers supported >> that link to boost, so I'm looking for a self-contained replacement >> that can be included in the distribution. I looked at Catch >> https://github.com/philsquared/Catch, but it tries to be too clever, >> resulting in too many issues. >> >> Any suggestions? > > I'm always willing to plug my own: https://github.com/kjgrahn/orchis > But it's very minimal, and you can tell I don't like the official unit > test ideology very much. > > I've used Google Test too, but I'm not very impressed. I remember them > making it hard to integrate with the build system, unless you choose > the build system /they/ like. That's a non-issue these days. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2017-01-04 21:34 +0100 |
| Message-ID | <o4jm15$th8$1@dont-email.me> |
| In reply to | #47823 |
Op 04-Jan-17 om 18:02 schreef Jorgen Grahn: > On Tue, 2017-01-03, Daniel wrote: >> I'm currently using the boost unit test framework for a project that >> doesn't otherwise depend on boost. The features that I'm using are >> BOOST_REQUIRE, BOOST_CHECK, BOOST_REQUIRE_EXCEPTION, >> BOOST_CHECK_EXCEPTION, and checking that there are no memory leaks. >> >> It's proving too difficult if not impossible to set up continuous >> integration builds for all the environments and compilers supported >> that link to boost, so I'm looking for a self-contained replacement >> that can be included in the distribution. I looked at Catch >> https://github.com/philsquared/Catch, but it tries to be too clever, >> resulting in too many issues. >> >> Any suggestions? > > I'm always willing to plug my own: https://github.com/kjgrahn/orchis > But it's very minimal, and you can tell I don't like the official unit > test ideology very much. > > I've used Google Test too, but I'm not very impressed. I remember them > making it hard to integrate with the build system, unless you choose > the build system /they/ like. I've been using the Google Test framework for a year now, and frankly I don't see what would make it hard to integrate it with a build system, or why it would prefer a particular build system. As far as I can tell it is pretty much build system agnostic. Of the C++ test frameworks I've had the (dis)pleasure to work with, including some "homebrew" and Boost, the Google Test framework is certainly not the worst. But it isn't that great either when compared to the test frameworks for other programming languages like C#. Though the Google test framework has a reasonable amount of documentation, it isn't all that well organized; I find myself googling a lot for the information I need rather than navigating through the documentation. I also find it somewhat lacking in the extendability department. But other than that it (mostly) does the job.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2017-01-05 08:49 +0000 |
| Message-ID | <slrno6s247.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #47829 |
On Wed, 2017-01-04, Dombo wrote: > Op 04-Jan-17 om 18:02 schreef Jorgen Grahn: ... >> I've used Google Test too, but I'm not very impressed. I remember them >> making it hard to integrate with the build system, unless you choose >> the build system /they/ like. > > I've been using the Google Test framework for a year now, and frankly I > don't see what would make it hard to integrate it with a build system, > or why it would prefer a particular build system. As far as I can tell > it is pretty much build system agnostic. We (the project I was in) may have overlooked something ... as I remember it, we ended up having to build it as part of the project, rather than installing it as a library. And it wasn't very clear /how/ to build it using Make; they shipped with CMake recipes. > Of the C++ test frameworks I've had the (dis)pleasure to work with, > including some "homebrew" and Boost, the Google Test framework is > certainly not the worst. My impression too. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-05 22:12 +1300 |
| Message-ID | <ed6h13F11foU6@mid.individual.net> |
| In reply to | #47838 |
On 01/ 5/17 09:49 PM, Jorgen Grahn wrote: > On Wed, 2017-01-04, Dombo wrote: >> Op 04-Jan-17 om 18:02 schreef Jorgen Grahn: > ... >>> I've used Google Test too, but I'm not very impressed. I remember them >>> making it hard to integrate with the build system, unless you choose >>> the build system /they/ like. >> >> I've been using the Google Test framework for a year now, and frankly I >> don't see what would make it hard to integrate it with a build system, >> or why it would prefer a particular build system. As far as I can tell >> it is pretty much build system agnostic. > > We (the project I was in) may have overlooked something ... as I > remember it, we ended up having to build it as part of the project, > rather than installing it as a library. And it wasn't very clear > /how/ to build it using Make; they shipped with CMake recipes. Usually projects just build gtest-all.cc :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2017-01-05 20:22 +0000 |
| Message-ID | <o4m9ud$1m0$1@news.xmission.com> |
| In reply to | #47805 |
[Please do not mail me a copy of your followup]
Daniel <danielaparker@gmail.com> spake the secret code
<a0695cca-5351-4a98-8549-576f399fc2d7@googlegroups.com> thusly:
>It's proving too difficult if not impossible to set up continuous
>integration builds for all the environments and compilers supported that
>link to boost [...]
What exactly is the difficulty?
When I worked at Fusion-io we supported a fairly large number of linux
targets, but most of these end up using the same compiler so the build
matrix isn't exactly one-to-one with platform. In the end, it
amounted to 3 variants: MacOS, linux and Windows. We built the
necessary dependencies for our build (including boost) and created
pullable packages for them from the build environment. So the build
environment just pulled down a prebuilt binary to link test
exectuables against.
This has the advantage that you don't spend CI build time rebuilding
dependencies that you aren't changing and it decouples the build
system used by the dependencies from the build system of the
application.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.c++
csiph-web