From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-02-09 03:49:54
Dean Michael Berris wrote:
> 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.)
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk