Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #47805 > unrolled thread

Suggestions for a unit test framework

Started byDaniel <danielaparker@gmail.com>
First post2017-01-03 09:13 -0800
Last post2017-01-05 20:22 +0000
Articles 10 — 7 participants

Back to article view | Back to comp.lang.c++


Contents

  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

#47805 — Suggestions for a unit test framework

FromDaniel <danielaparker@gmail.com>
Date2017-01-03 09:13 -0800
SubjectSuggestions 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]


#47806

FromCholo Lennon <chololennon@hotmail.com>
Date2017-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]


#47845

FromDaniel <danielaparker@gmail.com>
Date2017-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]


#47807

FromWouter van Ooijen <wouter@voti.nl>
Date2017-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]


#47823

FromJorgen Grahn <grahn+nntp@snipabacken.se>
Date2017-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]


#47828

FromIan Collins <ian-news@hotmail.com>
Date2017-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]


#47829

FromDombo <dombo@disposable.invalid>
Date2017-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]


#47838

FromJorgen Grahn <grahn+nntp@snipabacken.se>
Date2017-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]


#47840

FromIan Collins <ian-news@hotmail.com>
Date2017-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]


#47847

Fromlegalize+jeeves@mail.xmission.com (Richard)
Date2017-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