Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes: * Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation. We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html). We will be happy to accept your pull requests with improvements and notes in the mailing list. Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner. Once again, please review the new documentation and feel free to comment here or by sending us pull requests. Regards, Gennadiy Rozental
On Monday 25 May 2015 20:42:40 Gennadiy Rozental wrote:
Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes:
* Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html
This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation.
We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html). We will be happy to accept your pull requests with improvements and notes in the mailing list.
Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner.
Once again, please review the new documentation and feel free to comment here or by sending us pull requests.
Wow! I'm really glad to see the progress in Boost.Test development! Looking forward to see the merge to master. Congrats and many thanks to the team! I took a quick glance at the BOOST_TEST docs[1] - you print test duration in microseconds like "324mks". Isn't "us" the more common English abbreviation? It's been discussed on StackOverflow[2], too. PS: Yes, "μs" would be more correct, but it requires Unicode, so I'm not suggesting it. [1] http://raffienficiaud.github.io/test/boost_test/testing_tools/acceptable_sta... [2] http://stackoverflow.com/questions/28970229/what-is-the-mks-unit-reported-by...
Andrey Semashev
I took a quick glance at the BOOST_TEST docs[1] - you print test duration in microseconds like "324mks". Isn't "us" the more common English abbreviation? It's been discussed on StackOverflow[2], too.
PS: Yes, "μs" would be more correct, but it requires Unicode, so I'm not suggesting it.
Have no recollection how mks came to be. I am fine with us. Gennadiy
Le 26/05/15 06:18, Gennadiy Rozental a écrit :
Andrey Semashev
writes: I took a quick glance at the BOOST_TEST docs[1] - you print test duration in microseconds like "324mks". Isn't "us" the more common English abbreviation? It's been discussed on StackOverflow[2], too.
PS: Yes, "μs" would be more correct, but it requires Unicode, so I'm not suggesting it.
Have no recollection how mks came to be. I am fine with us.
Gennadiy
I updated the doc (+online) and code to "us". Best, Raffi
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Raffi Enficiaud Sent: 26 May 2015 13:07 To: boost@lists.boost.org Subject: Re: [boost] Boost.Test v3 is here
Le 26/05/15 06:18, Gennadiy Rozental a écrit :
Andrey Semashev
writes: I took a quick glance at the BOOST_TEST docs[1] - you print test duration in microseconds like "324mks". Isn't "us" the more common English abbreviation? It's been discussed on StackOverflow[2], too.
PS: Yes, "μs" would be more correct, but it requires Unicode, so I'm not suggesting it.
Have no recollection how mks came to be. I am fine with us.
Gennadiy
I updated the doc (+online) and code to "us".
Whoosh! Thanks Paul
On 5/25/2015 4:42 PM, Gennadiy Rozental wrote:
Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes:
* Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html
This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation.
We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html). We will be happy to accept your pull requests with improvements and notes in the mailing list.
Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner.
Once again, please review the new documentation and feel free to comment here or by sending us pull requests.
You do not make it clear on which branch v3 is at, but I assume you mean that it is on 'develop'.
Gennadiy Rozental
Boost.Test team is proud to present new version of Boost.Test library.
Thanks a lot! I switched all my local tests to the develop version the last couple of days and encountered no problems in the default configuration. The new documentation is great too. If I define BOOST_TEST_NO_OLD_TOOLS, I get a lot of compilation errors because of missing operator<< for the classes used with BOOST_TEST(a == b). Is that expected?
Marcel Raad
Thanks a lot! I switched all my local tests to the develop version the last couple of days and encountered no problems in the default configuration. The new documentation is great too.
If I define BOOST_TEST_NO_OLD_TOOLS, I get a lot of compilation errors because of missing operator<< for the classes used with BOOST_TEST(a == b). Is that expected?
If a and b do not have operator << overloaded then yes. You can use BOOST_TEST((a==b)) or can use BOOST_TEST_DONT_PRINT_LOG_VALUE(type) Gennadiy
On May 29, 2015 1:15:38 PM EDT, Gennadiy Rozental
Marcel Raad
writes: If I define BOOST_TEST_NO_OLD_TOOLS, I get a lot of compilation errors because of missing operator<< for the classes used with BOOST_TEST(a == b). Is that expected?
If a and b do not have operator << overloaded then yes.
You can use BOOST_TEST((a==b)) or can use BOOST_TEST_DONT_PRINT_LOG_VALUE(type)
That's a ridiculously long macro name for a not uncommon use case. ___ Rob (Sent from my portable computation engine)
Rob Stewart
BOOST_TEST_DONT_PRINT_LOG_VALUE(type)
That's a ridiculously long macro name for a not uncommon use case.
This is not a new API. Over the years I did not get complains from users. Apparently most types are streamable. Anyway, I can entertain an idea to rename this into something shorter if you have better alternative. Gennadiy
On May 31, 2015 1:08:09 AM EDT, Gennadiy Rozental
Rob Stewart
writes: BOOST_TEST_DONT_PRINT_LOG_VALUE(type)
That's a ridiculously long macro name for a not uncommon use case.
This is not a new API. Over the years I did not get complains from users.
I mistook the purpose of the macro. I see that it's a one-time call to disable streaming with a type rather than something to be repeated for each test using the non-streamable type. For that purpose, the name is fine. I'm sorry for the noise.
Apparently most types are streamable.
I wouldn't assume that. ___ Rob (Sent from my portable computation engine)
On 31/05/2015 22:48, Rob Stewart wrote:
On May 31, 2015 1:08:09 AM EDT, Gennadiy Rozental
wrote: Apparently most types are streamable.
I wouldn't assume that.
I often define stream operators in the unit tests rather than in the "real" code for types that I do not intend to be streamable in practice but for which I want to have useful error messages printed on test failure. Occasionally that leads me to move the operator into the real code later on, when it turns out that I also want to log it or something. (This is regardless of which unit test framework is in use -- when printing equality failures, most use either operator<< or some custom specializable/overridable method that usually falls back to operator<< if not otherwise overridden.) There are of course lots of types that it doesn't make sense to ever stream (because they're not value-like), but those rarely implement operator== either, so it's not an issue.
participants (8)
-
Andrey Semashev
-
Edward Diener
-
Gavin Lambert
-
Gennadiy Rozental
-
Marcel Raad
-
Paul A. Bristow
-
Raffi Enficiaud
-
Rob Stewart