Dave Steffen wrote:
Hi folks,
This is probably a question aimed at Gennadiy Rozental, but it may be of interest to the community in general.
We've been using the boost test library for about a year and a half now, and are happy customers. I'm revamping our unit test framework (e.g. revisiting the way we use boost test), and am specifically looking at the floating point comparisons.
One thing that I'm changing / hacking is the use of percentages to specify tolerance. We usually want answers to agree to (say) 1 part in 10^-12, and remembering to multiply or divide that by 100 is annoying. To this end, I'm defining our own set of comparison functions and macros, still using the stuff in ttdetail (e.g. fpt_abs and save_fpt_division).
How about: #define BOOST_CHECK_ACCURACY(x, y, acc) BOOST_CHECK_CLOSE(x, y, acc*100) Of course then the error messages aren't very readable :-( Like you I think the whole persentage thing was a big mistake: even though I know what the API does and use it all the time, forgetting to convert to a persentage is the by far the most common fowl-up.
Fine. Now, we want to be able to compare more complicated mathematical objects, such as vectors and matrices.
After some thought, we decided the responsibility for providing such functions is the responsibility of the mathematical object, not the unit test framework. That is to say, a function "relative difference between matrices" should be in Matrix.h, not some unit test thing.
Which leads to the idea of Matrix.h #including "boost/test/floating_point_comparison.hpp", which strikes me as rather odd. My first impulse was to copy/pull the relevent code out of floating_point_comparison.hpp and stick it in some more convenient place, where mathematical objects could use those functions to implement their own comparision functions.
Might this be a common idiom? Might we consider factoring these floating point comparison functions (not the BOOST_CHECK_CLOSE macro, but the functions it uses) out into a separate library? Any comments on my approach?
I think it is a common idiom, I had to jump though similar hoops for testing complex numbers, Genadiy's idea of using BOOST_CHECK_PREDICATE might work as well though (you could wrap the code in your own macro to simplify usage as well). John.