After delivering the keynote (with Tango dancing) Brian held a Fishbowl discussion on testing. This was moderated by Emily Bache. Here’s a few notes I took from the discussion, when I wasn’t participating:

• Test Maintenance – In the 90’s people tried to do testing, trying to be lean like Toyota. They said that TDD won’t work.
• Developers think that tests are beneath them. For some reason using the work “test” rubs devs up the wrong way.
• Failing tests show an idea which was valid for a previous iteration.
• See tests as a check list for design.
• Change UI, update tests, run tests.
• Help you ask “What is the code about?”. Break the code, delete/comment out method
• Failing tests are an indication you can write better tests
• Do we avoid TDD during maintenance/updates?
• Put a “best Before” date on your tests, forcing you to revisit them and maintain your tests as well as your code.
• If you don’t understand a test then there is too much detail!
• Test are to show abstracted behaviour.
• ABSTRACT
• Idea to get new starters (at company or on project) to do exploratory testing in order to understand system. Could this be seen as giving newbies the shit job?
• None of the names around testing are any good. They are confusing: Acceptance Tests, Unit Tests, Integration Tests etc.
• Tests are Rejection Checks
• Do you go to the test first, or the code when something goes wrong?
• Do you trust your tests?
• Do you need to make your tests clearer?
• Do you struggle to read other people’s tests
• Are Test Driven Design and Bug Testing Techniques different?
• TDD offers feedback on design and affords opportunity to refactor
• TDD still requires some upfront design!!!
• Test Maintenance – making old tests better! Don’t just need to do it for your code.
• “How will the world be different if you change the meaning of a phrase/word?”
• Do tests tell you that you were writing bad code at the time. SMELLS!
• Practice rewriting code you’ve already written
• Quantity drives Quality – repetition makes you better (KATA’s)
• Hardest question is always *what* are we supposed to build
• Tests document a decision made at one point in time.