This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Kent Beck on Testing Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

I listened to Kent Beck's talk "Developer Testing" earlier this week. I thought it'd be boring -- "write unit tests! yay!" -- but as I should have guesses, there were some good ideas about software development:

• Testing software addresses developers being accountable to each other people in the organization. Accountability isn't as bad as you might thing it is, because it means you spend less time arguing about things. If your software is "healthy," all your tests will run. If all your tests run, your software isn't healthy. End of story. No more debating.
• If can't easily write (unit) tests for your software, it means you have a poorly designed software. That is, being able to write tests for code isn't a test-writing problem, it's a design problem. With this idea, Beck all but says that J2EE is poorly designed: it's hard to impossible to test, thus it's poorly designed. "QED.", as they say.
• From the above, thinking about and planning for your software being testable starts right away when you're designing it, not afterwards. Indeed, in pure XP, you'd write the tests first. Testing first always seems to confuse people, it starts to make perfect sense when you sit down to test some nasty code for the 40th time and think, "man, if this was just designed a little better, they test would be so easy to write."

So, the main take away is: if you can't easily test your software, your software is probably poorly designed.