Thursday 25th October, 2012
9:30am to 11:00am
One thing that has discouraged people from incorporating TDD into their organization is the common misperceptions that tests should always be written first, before writing any production code, and, that tests and code should be developed in many tiny increments. We believe that TDD is more about thinking carefully about how best to validate that your software meets your requirements. Testing and validation should drive your development process (that’s why we are fans of being Test Driven), but we think there is so much more to testing than writing lots of unit tests.
The typical approach to TDD usually focuses on having developers write many unit tests that may or may not add value. Instead, we recommend you adopt a testing strategy that gives you the ost leverage. So, for example, rather than merely writing many unit tests, you can often get more value by defining the appropriate user-level acceptance tests. Testing should drive your development but not at the expense of every other coding and design practice). One size or one approach for testing does not fit every organization or team.
This talk challenges the “norm” for TDD. Testing should be an integral part of your daily programming practice. But you don’t always need to derive your code via many test-code-revise-retest cycles to be test-driven. Some find it more natural to outline a related set of tests first, and use those test scenarios to guide them as they write code. Once they’ve completed a “good enough” implementation that supports the test scenarios, they then write those tests and incrementally fix any bugs as they go. As long as you don’t write hundreds of lines of code without any testing, there isn’t a single best way to be Test Driven.
There’s a lot to becoming proficient at TDD. Developing automated test suites, refactoring and reworking tests to eliminate duplication, and testing for exceptional conditions, are just a few. Additionally, acceptance tests, smoke tests, integration, performance and load tests support incremental development as well. If all this testing sounds like too much work, well…let’s be practical. Testing shouldn’t be done just for testing’s sake. Instead, the tests you write should give you leverage to confidently change and evolve your code base and validate the requirements of the system. That’s why it is important to know what to test, what not to test, and when to stop testing. More discussion about Pragmatic TDD can be found here: http://adaptiveobjectmodel.com/2....
Sign in to add slides, notes or videos to this session