by Rebecca Wirfs-Brock & Joe Yoder

What do we mean by Pragmatic TDD?

Pragmatic Test Driven Development (TDD) is a practical approach to testing that focuses on the bigger picture of how testing best fits into and enhances your team’s software development practices. Rather than insisting that developers only write a lot of unit tests, you need to find a testing strategy that gives you higher quality software. You need to determine how testing best fits into your development context with your developers for your kind of software.

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 most 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.

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.

What do we mean by different testing rhythms?

We believe that you should pay attention to testing and that it should be an integral part of your daily programming practice. But we don’t insist that you always evolve tests along with your code in many short cycles. Some find it more natural to outline some 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, we think this style is OK too (and we don’t insist on one style over the other).

What are the testing practices you should consider?

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 get 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.

So, where should you start?

It is important to establish a team testing culture. Get the team on board using similar techniques and tools. Try some different approaches and then as a group reflect on what you’ve learned (have a retrospective). If you are starting a new project you might take a quite different approach than you would with an existing code base. It’s important to not get overwhelmed. Pick an area you want to focus on. For example, it’s much easier to write unit tests for new functionality. But sometimes you want to focus on writing tests for existing code that is buggy or needs to be modified. This can be more difficult. Maybe you want to concentrate on developing integration tests and automating them first (so that you can streamline your build and deploy process). It all depends on where you want to invest first. Just start modestly, grow your testing practices, and measure the impacts of your testing effort and benefits as you go. Of course the most important thing is to start somewhere and have testing become an important part of your development process.

{ 0 comments }

by Rebecca Wirfs-Brock & Joe Yoder

We’re excited to be offering a practical bent to testing. Test-driven development (TDD) traditionally means writing unit and acceptance tests along with production code. Some agile thought leaders push a hardnosed test-first practice, insisting that you always write a failing test before you write any production code. Then, in short programming and testing cycles, evolve your test as you complete your code.

One common objection to TDD done this way is that writing tests this way doesn’t seem “natural.” Instead, you may want to write a coherent chunk of code before writing any tests. We agree with that. In our course we explore several different ways you can do Test-Driven Development, making TDD much more approachable to a wider audience.

We believe that you should pay attention to testing and that it should be an integral part of your daily programming practice. But we don’t insist that you always evolve tests along with your code in many short cycles. Some find it more natural to outline some 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, we think this style is OK, too (and we don’t insist on one style over the other).

As long as you check in your production code along with unit tests that pass, your programming is being “driven” by tests.

We believe that it’s not so important to test first as it is to test frequently! Testing should be integral to your daily coding and design rhythms. And your production code should only be checked in along with its passing tests.

There’s a lot more 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. And acceptance tests, smoke tests, integration, performance and load tests support incremental development, too. If all this testing sounds like too much work, well…let’s get 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. That’s why it is important to know what to test, what not to test, and when to stop testing.

{ 0 comments }