Changes to tests

7 views
Skip to first unread message

Nicolas Alvarez

unread,
May 29, 2010, 8:52:01 PM5/29/10
to synecdo...@googlegroups.com
Greetings to all lurking developers, and spiders building webs in the
mailing list.

I plan to do some changes to how our unit tests are organized.

Instead of having tests for all of Synecdoche in a 'tests' directory, I will
put library tests in lib/tests/, client tests in client/tests/, etc. The
root "tests" directory will have shared code like TestRunner.cpp and
Util.cpp. Those files will probably be in a static library, so tests are
easier to compile.

I'll also change the CMake scripts to use CTest instead of custom CMake code
to run the tests. The only disadvantage is that "make test" won't compile
code first. The advantage is we can use the features of the ctest command
line tool, including running tests in parallel (-j2), running subsets of
tests (by regex), etc.

In addition, tests will be enabled by default (can be disabled with
BUILD_TESTING=0). Currently they are off by default, enabled with
ENABLE_TESTING=1.

If there are no comments, I'll be committing those changes soon.

--
Nicolas

(I read mailing lists through Gmane. Please don't Cc me on replies; it makes
me get one message on my newsreader and another on email.)

Nicolas Alvarez

unread,
Jun 3, 2010, 5:38:56 PM6/3/10
to synecdo...@googlegroups.com
Nicolas Alvarez wrote:
> I plan to do some changes to how our unit tests are organized.
>
> Instead of having tests for all of Synecdoche in a 'tests' directory, I
> will put library tests in lib/tests/, client tests in client/tests/, etc.
> The root "tests" directory will have shared code like TestRunner.cpp and
> Util.cpp. Those files will probably be in a static library, so tests are
> easier to compile.
>
> I'll also change the CMake scripts to use CTest instead of custom CMake
> code to run the tests. The only disadvantage is that "make test" won't
> compile code first. The advantage is we can use the features of the ctest
> command line tool, including running tests in parallel (-j2), running
> subsets of tests (by regex), etc.
>
> In addition, tests will be enabled by default (can be disabled with
> BUILD_TESTING=0). Currently they are off by default, enabled with
> ENABLE_TESTING=1.
>
> If there are no comments, I'll be committing those changes soon.

Okay, I'll commit CTest and the directory structure changes.


I'm also thinking about changing the test framework. Again.

The only reason we switched to UnitTest++ is that adding tests was much
easier, as we didn't have to remember "registering" newly-added tests.
However, I wrote some macros that give us the exact same easy syntax for
CppUnit.

Another good alternative is Google Test. One interesting feature is it has
assertion macros that terminate the test if they fail, and another set of
macros that report the failure but continue.

So our options are: staying with UnitTest++, switching to cppunit with my
simplifying macros, or switching to Google Test. But I haven't yet done a
full analysis, neither of the test frameworks nor of our needs...

--
Nicolas

Reply all
Reply to author
Forward
0 new messages