Dean Michael Berris wrote: [snip]
So the real answer to the question is that nothing actually stops you from using the BOOST_CHECK or BOOST_REQUIRE macros in Boost.Test -- I'm just looking to provide an alternative interface to defining specifications not only in Unit Tests, but also in different parts of the code. The goal really of the interface is for a novel "more English like" way of defining specifications, where it is explicit what the value being inspected is and what the expected behavior is.
Just my 0.02EUR (I've only previously glanced at the concept of BDD): - For end users writing acceptance tests (which is part of the ultimate goal, I guess) this still does not resemble English enough. - For developers writing unit tests, this is too verbose (might admittedly just be due to old habits). IMHO, it's easier to name the tests aptly, and keep the tests short and sweet. - For C++, its hard to get enough context out of such a test failure; the file + line needed to quickly locate the point of failure is unavailable (which is extremly useful when you're working in an IDE and can simply click the failure output to get to the exact location of the failure). - In general, I think that BDD needs to mature a bit more before incorporating the concept into Boost. It should be a good idea to see in what direction the acceptance wind in the general developer/tester community is blowing. For the moment, it feels more like an interesting experiment which _might_ be successful. IMHO, of course. - Why not continue to develop your library for a while outside of Boost, building upon the Boost libraries such as Boost.Test and make it available separately for the time being? Docs, docs ... Sorry if I'm saying things that have already been said - I didn't read through all of the posts in this thread. (As a rather funny sidenote, my respected coworker has always used the letters BDD as an acronym for "Brain-Dead Design". No offence meant.) Best regards, Johan Nilsson