Behavioral testing is the bee’s knees
I have been doing Test Driven Development (TDD) with xUnit-based frameworks (like unittest and NUnit) for a number of years now, and started with RSpec in Ruby and Jasmine in JavaScript a few months ago. RSpec and Jasmine are behavioral testing frameworks that facilitate Behavioral Driven Development (BDD). BDD is really no different from “normal” TDD except for the frameworks used. BDD frameworks facilitate a different way of designing tests.
Behavioral testing is awesome and makes xUnit-style testing seem barbaric and uncivilized in comparison. I didn’t see the big deal for a long time. My xUnit style tests served me just fine. But now I’m hooked.
If you are a TDD person (or do any unit testing), I encourage you to try out BDD. You should get the hang of it quickly. It can take a little while to learn BDD idioms, but once you start doing things like custom matchers, it’s absolutely amazing.
In future posts I’ll try to discuss more of the differences between TDD and BDD, but for now I just provide a hearty endorsement of BDD and frameworks like RSpec and Jasmine.
I’ve glanced at BDD with Gherkin and it sure looks interesting. I had you pegged as someone who’d favour clarity of code over text so it’s surprising to see you advocating it.
In my (still superficial) understanding of BDD I’m personally puzzled how text representation can be more clear than code. With a statement like “GIVEN 100 APPL shares”, how does anyone know “APPL” is a valid keyword? How is it known that “shares” can be used this way? It seems that discoverability is limited to looking at the underlying code… And what happens during refactoring, is there a way to avoid ending up with a sea of text to search/replace through?
For situations where I’m not the domain expert I see a need for this sort of abstraction, i.e. if we need accountants to write/validate tests then we need to find a way to express those tests outside of actual programming. And there might be high-level tests that require so much logic that my test-code is likely to include bugs on their own, so it makes sense to split apart data and logic. But you seem to be advocating BDD at a more fundamental level, for all developers writing unit tests, so I’m definitely looking forward to more of your thoughts and insights on this topic.
Jon, this is the only place that I’ve seen BBD used:
“For situations where I’m not the domain expert I see a need for this sort of abstraction, i.e. if we need accountants to write/validate tests”
My only experience with BBD is Cucumber. When I worked at ShermansTravel.com the woman who was both our project manager and also the head of the QA team was put in charge of writing the Cucumber rules. It was her job to talk to all the (non-technical) people in the organization and translate what they wanted into Cucumber rules. Thus the BBD was an act of translation, taking the words of people in various departments and putting their requests into a language that the developers could understand.
So just to be clear, RSpec and Jasmine are “just” Ruby and JS frameworks/libraries. They are not like Cucumber or tools like that, which use a new syntax/language/whatever. I would not enjoy doing that sort of BDD. This SO post gives a good example of the difference between the two: http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber
RSpec and Jasmine are the best of both worlds.