Ron has posted a great step-by-step tutorial for writing testable specs with cfSpec. Using an e-commerce shopping cart as an example, he builds up the spec, one expectation at a time, showing how cfSpec performs intuitive tests on the underlying objects, allowing you to write simple, expressive code, driven by your specification.

cfSpec now includes "stub" objects (with true "mock" objects coming soon) so that you can specify the behavior of components independent from each other (so you don't have to write multiple objects just to get one object's expectations satisfied).

After I get past a big project implementation later this month, I want to finally do TDD and start using mxUnit and maybe cfSpec. I understand they are different in approach, but are they mutually exclusive as far as a choice a developer would use for testing?

@Joshua, I wouldn't say they are entirely exclusive - they overlap to some extent - but I would say that BDD (cfSpec) is better for top-down development and TDD (MXUnit) is better for bottom-up. Does that help?

Hi Sean. Can you clarify what you mean by 'BDD (cfSpec) is better for top-down development and TDD (MXUnit) is better for bottom-up' ?

As far as I can see both are very 'agile' and can be used in a similar way. ie rather than writing a Test First mxunit test - red, green, refactor - we're doing the same with BDD - purple - green - refactor.

The benefits I see are a more descriptive language in the specs/tests and the possibility we can easily generate cfSpec's from use cases etc

But both seem 'botton-up' to me in the sense that we don't need to do a BIG design up-front. We just write a spec, watch it fail then write JUST ENOUGH code to make it pass.

@Alan, maybe it's a matter of perception but I find TDD frameworks fit better with lower level components since they are focus on specific actual vs expected results at an implementation level.

BDD focuses more on higher level behavior and allows multiple implementations for a single expectation and is also deals with "should" rather than "is" (which may be a subtle semantic difference but when you're designing a system, "should" is a better reflection of how you *expect* a system to behave rather than a series of detailed tests on specific values).

Does that make sense?

Thanks Sean. It sort of makes sense :-)

The way you describe it its almost as if as developers we can use both approaches but I always thought of it as BDD versus TDD as a choice otherwise you'll violate DRY ie a BDD cart.shouldBeEmpty() and a TDD ensureCartIsEmptyWhenCreated() do generally the same thing.

Next question would be: if there was a decent Eclipse plugin for cfSpec and good mocking options would you switch from mxunit for your tests, sorry specs? :-)

@Alan, boy you ask some difficult questions! :)

My rule of thumb would be to think about how much detail you normally put in a specification document. You specify expected behaviors of entities within the system but you don't necessarily go into mind-numbing detail.

I would use BDD for the same level of detail as I would write a spec and then use TDD for lower-level implementation stuff. I think I would be more likely to use TDD for maintenance and bug fixes, than BDD (create a test that fails to highlight the bug and then fix the bug and make sure the test passes).

Of course, right now I tend to use TDD for "everything" but it doesn't always feel very natural for the higher-level stuff because it requires you to be very explicit in your test code.

Bottom line, I suspect I will use both cfSpec and MXUnit going forward.

Another consideration is that BDD allows for regular human-readable "tests" whereas TDD requires a computer programmer to read the tests (which, of course, was part of the motivation for the folks who created BDD in the first place).

Thanks Sean. That makes sense!

Final question before I disappear :-)

So if BDD is used for higher level stuff would you run the 'specs' as part of CI in the same way you would run your suite of unit tests or would you leave BDD out of this and keep it as only a higher level tool for designing your software?

I'm guessing the BDD specs would not form part of your CI process

@Alan, that's a good question. As the tools stand today, yes, I would probably use MXUnit and unit tests as part of Continuous Integration (CI - for those folks who aren't sure what it means - is a process where your code is automatically "built" to a server and tested, usually every time code is checked into the repository, so that you can see as soon as any bugs are introduced). That does run the risk of violating DRY, of course, since you want as much coverage as possible in CI but if you're using BDD to assist design and unit test suites to support CI, you'll have some useful 'tests' in the specs.

I guess if the BDD tools expand to support programmatic output, suitable for use with ant and, say, JUnit Reports then I would move closer to using BDD for everything.

Of course, there's also a school of thought that views BDD as merely TDD using different terminology (this comes up on the testdrivendevelopment Yahoo! group from time to time)...

Name:
Email Address:
Comments *** Please note that all comments require moderation so it may be some time before your comment posts to this blog! ***
Remember My Information: