Understanding TDD/BDD
slug: understanding-tddbdd
I finally get it. I have used
TDD on a few of my
past projects, but I have always struggled with determining which tests
I should write. In my head I could see the code for the feature I was
working on, but I could not see the code for the tests for that feature.
That brings me to some code I was working on last night. In my quest to
become an open source developer, I was spending some quality time
playing around with the RSpec testing framework for Ruby. I was
working through a tutorial from IBM developerWorks.While technically
RSpec is a BDD
framework, it still follows the TDD idea of writing tests before writing
code and letting the tests guide the design. Unlike most testing
frameworks, RSpec lets you write tests in a form that resembles how you
would write the requirements in English. That is what finally made the
pieces fall into place for me. I now understand that the tests are
supposed to define the details of the requirements in code. As you write
more tests and then write the code the makes those tests pass, you
uncover more things that you need to write tests for. It makes for a
really nice feedback loop.
Using my newly-discovered knowledge, I built a small class up using
RSpec and following the loop. I have included that code here with the
hope it may help somebody else out there better understand how all this
works.
First, I have the RSpec test suite:
1 | require 'warehouse' |
And here is the code for the class under test:
1 | class Warehouse |
So now I am basking in my moment of enlightenment. I only wish I would
have figured all of this out sooner