Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Suggestions for a unit test framework
46 views
Skip to first unread message
Daniel
Jan 3, 2017, 12:14:16 PM1/3/17
to
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
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
Cholo Lennon
Jan 3, 2017, 1:36:43 PM1/3/17
to
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
Wouter van Ooijen
Jan 3, 2017, 1:42:00 PM1/3/17
to
Op 03-Jan-17 om 6:13 PM schreef Daniel:
catch?
Wouter "Objects? No Thanks!" van Ooijen
> 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?
>
> 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?
catch?
Wouter "Objects? No Thanks!" van Ooijen
Jorgen Grahn
Jan 4, 2017, 12:03:06 PM1/4/17
to
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 .
Ian Collins
Jan 4, 2017, 2:37:31 PM1/4/17
to
--
Ian
Dombo
Jan 4, 2017, 3:32:22 PM1/4/17
to
Op 04-Jan-17 om 18:02 schreef Jorgen Grahn:
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.
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.
Jorgen Grahn
Jan 5, 2017, 3:49:21 AM1/5/17
to
On Wed, 2017-01-04, Dombo wrote:
> Op 04-Jan-17 om 18:02 schreef Jorgen Grahn:
...
> 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
>> 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.
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.
Ian Collins
Jan 5, 2017, 4:13:19 AM1/5/17
to
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 :)
> 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.
--
Ian
Daniel
Jan 5, 2017, 10:31:20 AM1/5/17
to
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.
>
> Boost.Test can be used without compiling it and as a subset of the whole
> Boost
Daniel
Richard
Jan 5, 2017, 3:22:49 PM1/5/17
to
[Please do not mail me a copy of your followup]
Daniel <daniel...@gmail.com> spake the secret code
<a0695cca-5351-4a98...@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>
Daniel <daniel...@gmail.com> spake the secret code
<a0695cca-5351-4a98...@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
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>
0 new messages