Re: BDD and TDD - What are they for?

Clinton D. Judy wrote:

> I'd like someone to give me very basic reasons for why I need Behavior
> Driven Development (BDD, see RSpec) and/or Test Driven Development (TDD,
> See Test::Unit).

Shine the "Phlip" symbol on the underside of the nearest cloud deck!

> I'm a fairly competent programmer. I think I use what they call an
> "iterative" style of programming; I don't rush out to build the entire
> program at once. I do a very small framework, then attempt to run it and
> see if it's giving me the result I expect. If it's not, then I figure
> out what's going wrong, and attempt to solve it before going on to the
> next small part. You could say I do several iterations in an hour, to
> give an idea of time.

When you say "attempt to run it", you should be mixing manual testing with 
running unit tests. They give a second opinion.

However, they are permanent. Imagine if you put a "mini-me" in a bottle, who 
came out and manually tested, instantly, each time you changed the code. Imagine 
if it would warn if nearly any behavior changed since the last run.

You could go faster - making bigger changes - with less manual testing.

> It looks like TDD does exactly what I'm doing, but introduces far more
> code to the equation.

Yet that code should be super-easy to write. A TDD test should obey the Assemble 
Activate Assert pattern:

   def test_case
     foo = assemble_foo()
     result = foo.activate()
     assert{ result == 42 }
   end

Compared to production code, that test code looks super-easy to write. Tip: The 
easier a test is to write, the cleaner and more decoupled your code is. So, 
counter-intuitively, the more lazy you get writing tests, the more pressure 
forces your code to decouple.

To do TDD, you write the test case first, then write code to pass the test. You 
only write new code if you have a failing test case. So your code is decoupled 
before it is even written.

 > One of the biggest features of TDD is being able
> to run a suite of tests to make sure new features don't break old
> features. Yet I have an eye for this while developing; I either fix the
> upcoming problem because I know it's going to happen, or I'm doing it
> wrong in the first place. Sure, I occasionally miss, but who doesn't? I
> find the issue as quickly as I can and resolve it in a clean style.

You should run a TDD test suite after the fewest possible edits: 10 at the most, 
and hopefully just 1. A coding session should go type-type Test, type-type Test, 
type-type Test, in tiny cycles.

If you delay to run the test, the more risk you absorb with your edits.

This helps sustain projects as they get huge; the code stays just as easy to 
work with as a tiny project. Nobody can cross-check everything in a huge program.

> BDD looks like a way to make it easy for non-programmers to do
> programming, but not having people keep several functions in mind at any
> one time. And it also does TDD? Am I close?

Yes - BDD is TDD with an added layer: A "literate programming" framework that 
forces you to think in clear English* statements that your client could understand.

*or whatever your client speaks!

That anyone can do TDD with BDD (and they do) speaks volumes about Ruby's 
ability to support easy and flexible DSLs.

> But everyone continually praises TDD and BDD, which leads me to believe
> I'm missing something profound that could make me a better programmer.
> So what's the big deal?

The big deals are: Almost no debugging, a super-high velocity, the ability to 
deploy any integration, the ability to rapidly share code with colleagues, code 
that strongly resists new bugs, and the ability to allow your client to "steer" 
your project, feature-by-feature, in real-time.

If your tests fail unexpectedly, the fault must lie in your last edit. You can 
undo or revert it. If your tests gate your Subversion or Gitorious version 
controller, then you know that you can always revert your code to get rid of a 
test failure. Working in tiny cycles, and constantly integrating your code, 
allows you to take bigger steps with more confidence.

Debugging is the greatest time-waster in all programming. Grizzled senior 
programmers (like some of my friends!) can all remember working on projects with 
bugs so big, you could spend the first week just isolating which module 
contained the bug. With debugging out of the way, you spend your remaining time 
understanding requirements, implementing them, integrating them, and deploying 
them. Your project goes very fast as your client learns to request very small 
features, each an increment over the existing features. Very few features go to 
waste. And a project with a complete test rig cannot lose its value over time. 
New code is often easier to write than old code, even despite projects with 
thousands of features. This metric is unheard of in software engineering, where 
new features are typically harder to write than the first ones.

If your tests gate your integrations, than you could deploy any integration. It 
might have unfinished features (and you might make their View buttons 
invisible!), but the tests will tell you it has no bugs. This metric is also 
unheard-of in classical programming, where a project typically must endure a 
"polish phase", as much as 25% of development time, to get it "ready to ship".

Next, if I need my colleagues to be able to mess with code I wrote (and vice 
versa), then I don't need them breaking it because they didn't understand it 
(what are the odds?:). If they run my tests (and they do!), then there's a 
little bit of me in them, working with them, keeping my features stable while 
they add theirs.

The TDD cycle has three steps: Write a test that fails for the correct reason, 
write simple code that passes the test, and refactor your code to make it clean 
and dry. Notice you don't refactor until the code passes its test. Refactoring 
means merging the new code with the preexisting code. And you don't refactor 
until your tests say the new code works. This implies only good code with valid 
features gets merged together. TDD's influence on design cannot be understated: 
It produces rock-solid code that strongly resists bugs.

Under classic software development, you would ask your client for a long list of 
features, then ask to be left alone for a while! Under TDD, your new features 
can be reviewed _as_ they emerge. Your client has better odds of getting the 
features they want if they practice "just in time requirements". They only 
require features in small increments from those installed features which they 
like. TDD allows a business cycle as short as a week to add features, review the 
code, and request for features. This improves the odds your client gets the 
features they need - not just some of the features they ask for. Your client no 
longer has the burden of predicting the future and planning every feature they 
might need.

The Ruby on Rails project has copious unit tests; its success is an example of 
these forces at work...

-- 
   Phlip