Development Methodology & Processes

Development Methodology (Agilesque)

TDD - Test Driven Development

__Outline __

1. Write a test based on requirements.
2. Run the test, and watch it fail.
3. Write the simplest code you can to make the test pass.
4. Run the test and watch it pass.
5. Improve the code as required to make it perform well, be readable and reusable,but without changing its behavior.
6. Repeat the cycle.

Kent Beck ‡ suggests this way of working brings benefits in four clear areas:

1. It helps prevent scope from growing—we write code only to make a failing test pass.
2. It reveals design problems—if the process of writing the test is laborious, there’s a sign of a design issue; loosely coupled, highly cohesive code is easy to test.
3. The ongoing, iterative process of demonstrating clean, well-written code, with intent indicated by a suite of targeting, automated tests, builds trust with team members, managers, and stakeholders.
4. Finally, it helps programmers get into a rhythm of test, code, refactor—a rhythm that is at once productive, sustainable, and enjoyable.

BDD

In practice, the problems we solve pretty much always fit into one of three categories:

1. Help the customer make more money.
2. Help the customer spend less money.
3. Help the customer protect the money they already have. Around this recognition grew up an evolution of TDD focused specifically around helping developers write code that matters. Just as TDD proved to be a hugely effective tool in enhancing the technical quality of software, behavior-driven development (BDD) set out to enhance the success with which software fulfilled the business’s need. The shift from TDD to BDD is subtle, but significant. Instead of thinking in terms of verification of a unit of code, we think in terms of a specification of how that code should behave—what it should do. Our task is to write a specification of system be- havior that is precise enough for it to be executed as code.