3 ms·

Google's gtest (and gmock) is a wonderful piece of C++ code. It needs very small amount boilerplate, less than most junit based frameworks (which is amazing, gi

Google's gtest (and gmock) is a wonderful piece of C++ code. It needs very small amount boilerplate, less than most junit based frameworks (which is amazing, given this C++ that we are talking about) and great mocking abilities (for C++). I don't see how this CATCH can match it anytime soon. Headers-only approach is interesting but can be bad for compilation performance, which is very very important when projects grow in size.

ot 16y ago
The headers are included only in test code which is usually in separate compilation units, so the compile times shouldn't be a problem
- phil_nash 16y ago
  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.
phil_nash 16y ago
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.
shin_lao 16y ago
If your project is template intensive you're going to have long compilation time. Our work around is parallel compilation.

ot 16y ago

The headers are included only in test code which is usually in separate compilation units, so the compile times shouldn't be a problem

phil_nash 16y ago
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.

phil_nash 16y ago

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.

shin_lao 16y ago

If your project is template intensive you're going to have long compilation time. Our work around is parallel compilation.