Testing Fishbowl Discussion – Brian Marick #xp2011

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.
It’s a bit fragmented, but I think I captured many of the points raised and discussed. ( :

What did you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s