"Max Chasing" <MKhesin@liquidnet.com> wrote in message news:4B6FB7F60D37D41188C300B0D022E0C003965168@exchange.lnholdings.com...
http://www.gamesfromwithin.com/articles/0412/000061.html Well, some good marks but no victory. Perhaps the people involved in the library will find this useful. cheers, max
Hi, I don't have much to say about this article, other then some statements seems questionable and many people have different priorities and requirements for testing framework. One thing needs to be spelled out though: Boost.Test *does* support fixtures. At least in a sense author using this term. Noel found proper thread in mailing list to refer, but made completely wrong conclusion from it. To implement fixtures one needs to use constructor and destructor *for fixture*. Here an example: struct my_fixture { my_fixture() { /* do initialization here */ } ~my_fixture() { /* do deinitilaization here */ } T1 obj1; T2 obj2; .... }; ... TEST( test1 ) { my_fixture fx; // test body here } TEST( test2 ) { my_fixture fx; // test body here } TEST( test3 ) { my_fixture fx; // test body here } That's all. You even got a "bonus" ( in author terms ) that it lets you declare objects used in the fixture on the stack. I admit I may had to explain it in docs/FAQ. But seems obvious in modern C++. (Actually in prerelease version of the library there were additional interfaces to support fixtures. But I dropped them later since I realized we don't really need them in C++). One thing though may worth considering: add support for fixtures on test_suite level, so that one needs to specify them once during test_suite initialization in a form of two setup/teardown methods or fixture type. I may add it next release. Gennadiy P.S. I would like to see author to apply "one assertion per test case" policy in real life. In my experience single unit test program may contain hundreds of them.