Test Driven Development -

TDD

What is the worst factor that jeopardize quality?

• It stops new team members from changing things because they don't understand the system, and it stops experienced people changing things because they understand it all too well.

Fear is the mind-killer.

• The primary goal of unit testing is to prevent fault, not to find them.

• Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole.

• Good unit test are those that:• Runs fast.

• Helps us to localize problems.

• Can be used as a specification of the unit.

What is unit test?

Approximate distribution of faults

Fault of omission

Low level faults

⅓

⅓

⅓

More efficient and focused testing gives more output for the

same effort and with that faster time to market and higher quality.

NO Unit Test

Test-Driven Development (TDD) is a technique for building software that guides software development by writing tests. It was developed by by Kent Beck in the late 1990's as part of Extreme Programming. In essence you follow three simple steps repeatedly.

TDD - Martin Fowler

• Drives sound architecture and design (Clean Code) – it’s more difficult to write tests otherwise.

• Easier to understand the behavior of the code – makes it easier to spot missing behaviors. (~40% of failures are fault of omission).

• Clear view of how far development has proceeded – less stress.

• Easier to refactor the code – safety net for change.

Main points of TDD

• “The most common way that I hear to screw up TDD is neglecting the third step. Refactoring the code to keep it clean is a key part of the process, otherwise you just end up with a messy aggregation of code fragments. (At least these will have tests, so it's a less painful result than most failures of design.)”

TDD - Martin Fowler

• TDD give you the confidence to do long-term development because with component tests in place, you know that your foundation code is dependable.

• TDD give you the confidence to refactor your code to make it cleaner and more efficient.

• TDD also save you time because component tests help prevent regression faults from being introduced and released.

• Another advantage is that component tests provide excellent implicit documentation because they show exactly how the code is designed to be used.

Value of TDD

• Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

• From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality.

TDD Benefit

VALUE OF TDD

“On questions on

programmer

productivity, an

overwhelming majority

of the developers

believed that TDD

approach facilitates

better

requirements

understanding (87.5%)

and reduces debugging

effort

(95.8%).” - An Initial

Investigation of Test Driven

Development in Industry, Boby

George, Laurie Williams

• “When we need to change code, we should have tests in place. To put tests in place, we often have to change the code” – Micael C. Feathers

Legacy Code Dilemma

• Drives sound architecture and design (Clean Code) – it’s difficult to write tests otherwise.

• Easier to understand the behavior of the code – makes it easier to spot missing behaviors. (~40% of failures are fault of omission).

• Clear view of how far development has proceeded – less stress.

• Easier to refactor the code – safety net for change.

Main points of TDD

› Instead of1.Do a lot of changes2.Fix a lot of unit tests3.Repeat› Try1.Plan a small change2.Change the relevant unit test(s)3.Change relevant code4.Repeat

TDD Maintance

› Writing test code normally takes less effort then implementing.

› It like stating “that no three positive integers a, b, and c can satisfy the equation an + bn = cn for any integer value of n” – it took 358 years and a 150+ pages of proof.

› “Now when I test drive, I start with writing a test which usually takes me few minutes (about 5 minutes) to write. The test represents my scenario. I then start implementing the code to make the scenario pass, and the implementation usually takes me a lot longer (about 50 minutes).” - Miško Hevery, Google

TDD Effort

• Not providing sufficient training, education, and mentoring

• Not using a Mocking Framework

• Writing Tests Retrospectively

• Line coverage obsession

• Completely reducing initial modeling

• Completely reducing parallel independent testing

Common TDD Mistakes