"Noticing the pain as soon as possible and then fixing the problem - whether it is a rigid design, fragile tests or something else - requires skill. Not everybody is alert to the pain, but instead they keep on writing bad code until making changes becomes too expensive and a rewrite is needed. Not everybody fixes the problem when they feel the pain, but instead they implement a quick hack and leave an even bigger mess for the next developer. But for those who have the necessary skills and discipline, TDD can be a powerful tool and they can use it to write better code."

"Imagine the scene. You are eleven years old, and in the five minutes before the end of the lesson, your Maths teacher decides he should make his class more "fun" by introducing a "game". He explains that he is going to point at each pupil in turn and ask them to say the next number in sequence, starting from one. The "fun" part is that if the number is divisible by three, you instead say "Fizz" and if it is divisible by five you say "Buzz". So now your maths teacher is pointing at all of your classmates in turn, and they happily shout "one!", "two!", "Fizz!", "four!", "Buzz!"... until he very deliberately points at you, fixing you with a steely gaze... time stands still, your mouth dries up, your palms become sweatier and sweatier until you finally manage to croak "Fizz!". Doom is avoided, and the pointing finger moves on. Until the next time."

"Things to keep in mind.

No matter where you start, start with one simple test. One assertion, if you can manage it.
Write the code to make that test pass
Then refactor -- this part is critical, this is where the creative design is with a TDD process.
Then write the next test.
In Rails, you'll often start in the controller then realize that code needs to be written in the model (or vice-versa). Write a separate test for the model -- testing models from the controller makes it hard to test all the model logic.
It's okay to plan the tests in advance, but you should only work on one test at a time. (Sometimes I'll write the series of tests, then comment out all but one)"

"FakeWeb is a helper for faking web requests in Ruby. It works at a global level, without modifying code or writing extensive stubs."

"Variation: Saboteur
A Test Stub that is used to inject invalid indirect inputs into the SUT is often called a "Saboteur" because its purpose is to derail whatever the SUT is trying to do so we can see how the SUT copes with these circumstances. The "derailment" can be caused by returning unexpected values or objects, or it can be caused by raising an exception or causing a runtime error. Each test may either be a Simple Success Test or an Expected Exception Test (see Test Method) depending on how the SUT is expected to behave in response to the indirect input."

"RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse syntax."

"RSpec, Cucumber, Webrat, RCov and Autotest are a powerful combination of tools for testing your Rails app. Unfortunately getting them to all work nicely together can be a bit of challenge. I recently configured a development environment from scratch on OS X 10.5 Leopard and kept track of all of the little details."

"Machinist generates data for the fields you don't care about, and constructs any necessary associated objects, leaving you to only specify the fields you do care about in your tests."

"My experience so far, as I explore what Cucumber can do, has been largely positive. Where I was starting with Cucumber and only a vague idea of how the user interaction would play out, writing the scenarios at the Cucumber level felt very valuable and gave the development a clear path that I wouldn't have otherwise had. That said, there is extra code being written, and it's clearly possible to get really tangled in getting the step definitions right."

"I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time."

"When viewed in development mode, the person div would be overlaid with a translucent gray box with the words “Milestone 6” in it, as shown below."

"We’ve been writing a “feature” for every new client request on that project – for each user-created ticket we handle, we create a .feature file (and include the ticket number in the feature title), and write steps for that request. This means that we have acceptance tests for all new client requests on that project. This approach may seem a little strange, but it’s been helpful, and we’re very happy with it so far. We’ll likely take a different approach if we use Cucumber on a project from scratch.

Now you have no excuse if your projects aren’t doing any kind of top-down testing, so get out there and write some acceptance tests!"

"The Shoulda gem makes it easy to write elegant, understandable, and maintainable Ruby tests. Shoulda consists of test macros, assertions, and helpers added on to the Test::Unit framework. It’s fully compatible with your existing tests, and requires no retooling to use."

"But enough of irony. Is this useful? I think it may be. You see, one of the great benefits of describing a problem as a Finite State Machine (FSM) is that you can complete the logic of the problem. That is, if you can enumerate the states and the events, then you know that the number of paths through the system is no larger than S * E. Or, rather, there are no more than S*E transitions from one state to another. More importantly, enumerating them is simply a matter of creating a transition for every combination of state and event.

One of the more persistent problems in BDD (and TDD for that matter) is knowing when you are done. That is, how do you know that you have written enough scenarios (tests). Perhaps there is some condition that you have forgotten to explore, some pathway through the system that you have not described."

An excellent talk on testing legacy code. Some great insights on how to use judicious refactoring and contingent testing. Not too Ruby-specific.

beautiful interactive test-encompassed lessons

Just worth posting on the wall, is all.

'Below is a “getting started” tutorial, a helpful autotesting plugin, and hints about a TextMate bundle for Javascript Unit Testing and a future Peepcode on Javascript Unit Testing.'

"In the beginning, the Product Owner identified a Need. And the Need was without form, and void; and darkness was upon the face of the deep. And the Spirit of the Team (Team) moved upon the face of the Need and asked some questions."

Great TDD kata from UncleBob. Unfortunate it's PowerPoint; would be nice if it were a PDF. But it's legible.

New version of NUnit testing framework is released.

"An interesting aside in favour of agile development techniques in general and TDD in particular is that even in this state the code is often much more robust and a much better functional fit than code developed under more traditional methods based on lar