21–30 of 31 posts
To be honest, I prefer bandit[1], it uses lambdas instead of macros which I consider more modern and it has a nice syntax to it. Anyone interested in catch should also check out bandit. [1] http://banditcpp.org/index.html
To be honest, I prefer bandit[1], it uses lambdas instead of macros which I consider more modern and it has a nice syntax to it. Anyone interested in catch should also check out bandit. [1] http://banditcpp.org/index.html
I found the Bandit examples rather disorienting. Can anyone explain what the "[&](){" business means?
CPP reference has a nice overview of it: http://en.cppreference.com/w/cpp/language/lambda
Anyone know of a really good (preferably simple and pragmatic) C++ mocking/stubbing framework to go with this?
I don't really see the advantage of Catch over http://unittest-cpp.sourceforge.net/ UnitTest++ was written by Noel Llopis, is small, tasteful, fast, and supports fixtures (and nested fixtures) via structs and struct inheritance. Honest question: Why would I use Catch instead?
We don't do unit-testing as part of our official development process where I work, so I was looking for something that I could quickly try out and get started with in my spare moments. I read about several frameworks and Catch seemed to fit the bill best.
Looking over the UnitTest++ web site just now it appears to be nearly as easy as Catch, so if I had found it first I probably would have given it a try.
For those not currently doing any unit testing who want to get a feel for what it is all about, I highly recommend Catch as a "my first unit testing framework."
To be honest, I prefer bandit[1], it uses lambdas instead of macros which I consider more modern and it has a nice syntax to it. Anyone interested in catch should also check out bandit. [1] http://banditcpp.org/index.html
AssertThat(guitar->sound(), Equals(sounds::clean));
CHECK(guitar->sound() == sounds::clean);
To be honest, I prefer bandit[1], it uses lambdas instead of macros which I consider more modern and it has a nice syntax to it. Anyone interested in catch should also check out bandit. [1] http://banditcpp.org/index.html
One advantage of Catch is that you can use native C++ expressions in your assertions, so instead of AssertThat(guitar->sound(), Equals(sounds::clean)); you can write CHECK(guitar->sound() == sounds::clean); And you'll still get sensible output when it fails, showing the expression and the result of guitar->sound().
I'm not a C++ programmer but this looks really neat and tidy. How does it work?
It looks like a nice test framework, but it doesn't appear to help at all with the really hard problems you face with testing C++ -- isolating the unit under test for separate compilation, and the development and inclusion of mocks/stubs. Anyone know of a really good (preferably simple and pragmatic) C++ mocking/stubbing framework to go with this?
https://mrzechonek.github.io/tut-framework/
It's lightweight, easy to setup for separated tests or built in tests, and simple to use. Doesn't add anything to help with mocking, but you can do that yourself.
EDIT: To followup, I created a C++ template that leverages TUT and binfmtc that I could use to rapidly iterate with. I used it for working out solutions to problems in "Thinking in C++"; it's posted at http://hardcorehackers.com/~npsimons/Template.hh
This looks hella good, I particularly am intrigued by the nested setup/teardown system. The natural assert syntax is interesting, too, amazing what macros can accomplish. Appropriately, the first question that came to mind was, "what's the catch?" :)
Yup. I found it interesting after a co-worker pointed it out to me because it looks and works kind of like RSpec. We are currently considering using it for a new project and it seems mature enough to give it a go. I'm currently toying with writing a JSONReporter so we can use that as an additional test result output format and I agree, so far it seems to be a really well done project.
That said, inline setup/teardown and parsing expressions in asserts seem like such natural ideas, I can't believe I haven't run across frameworks doing them before. I guess the shadow of JUnit is extremely long.