Floating point comparisons are achieved through the Approx helper class. E.g:
REQUIRE( pi == Approx( 3.14159265358 ) );
(and yes, I know pi to a lot more digits than that!)
The style you suggest is almost supported out of the box, and I've been considering fully supporting it - especially for container oriented tests.
As to the test naming - the idea is that you provide a short, hierarchical name, and a longer description (so the description is in addition to the test name):
TEST_CASE( "example/test1", "Such and such should do so and so" )
To run a test you need only specify the name (example/test1) - or a part of the name (e.g. example/*) (allowing tests to be easily grouped into suites with no extra work).
Arguably compilation time of your test code is even more important! You don't want to be kept waiting for feedback in a TDD cycle. I agree that compilation time can be a limiting factor of the header-only approach (actually link time may be the killer). But it's generally easier to give a header-only library support for libs than the other way around. I plan to keep header-only as the default way of using CATCH.
I hear you on the compilation time. I've not yet found it to be a problem but I haven't used it at large scales yet. I'm considering support for a lib based alternative version for larger scale use (I believe boost.test has the same approach).
As for gtest, I believe I already a decent amount of the same ground. In same cases I do things different ways, so it's difficult to compare directly. In others it may be simply a matter of "coming soon".
I don't see anything in gtest that is not already supported or readily achievable in CATCH.
What I'm not planning on supporting directly is mocking support - but there is no reason why gmock couldn't be used here.
You make a good point and I have put in some workarounds for this already. I'll probably put more in over time.
The trade-off is that I didn't want to over-use expression templates so I have kept it to one level. But my aim is to at least allow arbitrary expressions to compile and correctly report failures. It should also detect when the expression cannot be decomposed and report this in the output so you can rewrite the expression if you do hit it. I have done this for some operators already.
Mocks and fakes are not directly supported, however if you are rolling your own CATCH allows test code to be called back by your application code.
Although I haven't tried it yet there should be no problem using CATCH with a third-party mocking framework.
(and yes, I know pi to a lot more digits than that!)
The style you suggest is almost supported out of the box, and I've been considering fully supporting it - especially for container oriented tests.
As to the test naming - the idea is that you provide a short, hierarchical name, and a longer description (so the description is in addition to the test name):
TEST_CASE( "example/test1", "Such and such should do so and so" )
To run a test you need only specify the name (example/test1) - or a part of the name (e.g. example/*) (allowing tests to be easily grouped into suites with no extra work).