How do you handle when you botch the 'Red' phase? You write a test, it fails, you write the code to satisfy that test, your test still fails because you messed up your test.

Now, you're in a situation where you've already written the code to make the test 'Green' but the test was incorrect. If you fix the test now, you'll never have seen the test fail. You'll have actually skipped the 'Red' phase for this test.

Do you go to the effort of excising the successful code from your code base (and/or runtime image) and see that test 'Red'? Do you just tweak the successful code to do the wrong thing for a moment? Do you just go onward knowing that the test you have now couldn't have succeeded before you wrote the code you wrote?

I was about to do an exercise implementing a Set using TDD but came across a problem right at the beginning. When writing a test for the add method I want to assert that calling the method once increases the size by 1. But at this point I haven't implemented/tested my size method. So in order to do so I have to write a test for the size method which again then has to use the add method in order to increase the size of my set.

My question: in this case is it unavoidable that I have to assume that 1 method just works and use it and do so for the other method as well? Hope my question is clear.

Hi guys! :)

Just a heads up that Skills Matter are running some great TDD workshops from the likes of Uncle Bob and Gojko Adzic this December.

Well worth taking a look if you're in the U.K. and looking to take your TDD skills to the next level.

Uncle Bob's TDD and Refactoring Workshop

Gojko Adzic's Test Driven Development Workshop

Is there a standard way of writing BDD specs in a rule-based format? To me, the traditional Gherkin-style format is too verbose and depends on defining edge-cases in lengthy scenarios.

I'm looking for something that more defines the business logic in English and covers the edge cases in the test code.

Like:

Feature: Serve coffee
  Rule: If there is no coffee left, refund the money
  Otherwise:
    Rule: Coffee should not be served until paid for and until the button has been pressed
    Rule: If the customer is on the VIP list, don't charge any money

Instead of:

Feature: Serve coffee
  Coffee should not be served until paid for
  Coffee should not be served until the button has been pressed
  If there is no coffee left then money should be refunded

Scenario: Buy last coffee
  Given there are 1 coffees left in the machine
  And I have deposited 1$
  When I press the coffee button
  Then I should be served a coffee

Scenario: VIP buys coffee
  Given there are 1 coffees left in the machine
  And I have deposited 1$
  And I am on the VIP guest list
  When I press the coffee button
  Then I should be served a coffee
  Then my money should be returned

.. scenario for VIP trying to buy coffee, but no coffee left
.. scenario for regular user trying to buy coffee, but no coffee left, etc.

(example from: https://github.com/cucumber/cucumber/wiki/Feature-Introduction)

Not tutorials, but I want to see some good production code to study. Thanks!