Приглашаем посетить
Чуковский (chukovskiy.lit-info.ru)

Chapter 9.  Test-First Programming

Previous
Table of Contents
Next

Chapter 9. Test-First Programming

Unit tests are a vital part of several software development practices and processes, such as test-first programming, Extreme Programming,[3] and test-driven development.[4] They also allow for design-by-contract[5] in programming languages that do not support this methodology with language constructs.

[3] http://en.wikipedia.org/wiki/Extreme_Programming

[4] http://en.wikipedia.org/wiki/Test-driven_development

[5] http://en.wikipedia.org/wiki/Design_by_Contract

You can use PHPUnit to write tests once you are done programming. However, the sooner a test is written after an error has been introduced, the more valuable the test is. So, instead of writing tests months after the code is "complete," we can write tests days, hours, or minutes after the possible introduction of a defect. Why stop there? Why not write the tests a little before the possible introduction of a defect?

Test-first programming, which is part of Extreme Programming and test-driven development, builds upon this idea and takes it to the extreme. With today's computational power, we have the opportunity to run thousands of tests, thousands of times per day. We can use the feedback from all of these tests to program in small steps, each of which carries with it the assurance of a new automated test, in addition to all the tests that have come before. The tests are like pitons, assuring you that no matter what happens, once you have made progress, you can only fall so far.

When you first write the test, it cannot possibly run because you are calling on objects and methods that have not been programmed yet. This might feel strange at first, but, after a while, you will get used to it. Think of test-first programming as a pragmatic approach to following the object-oriented programming principle of programming to an interface instead of programming to an implementation: while you are writing the test, you are thinking about the interface of the object you are testingwhat does this object look like from the outside? When you go to make the test really work, you are thinking about pure implementation. The interface is fixed by the failing test.

What follows is a necessarily abbreviated introduction to test-first programming. You can explore the topic further in other books, such as Test-Driven Development: By Example by Kent Beck (Addison Wesley) or Test-Driven Development: A Practical Guide by Dave Astels (Prentice Hall).


Previous
Table of Contents
Next