Unit testing history
First time mentioned in "The Mythical Man-Month"
(1975) by Fred Brooks.
Described in detail in "The Art of Software Testing"
(1979) by Glenford Myers.
In 1987 IEEE adopted special standard of software unit
Kent Beck set out the main ideas of TDD in his book
"Extreme Programming Explained“ (1999).
Test-driven development (TDD)
Software development process that relies on the repetition
of a very short development cycle: first the developer writes
an (initially failing) automated test case that defines a
desired improvement or new function, then produces the
minimum amount of code to pass that test, and finally
refactors the new code to acceptable standards. Kent
Beck, who is credited with having developed or
'rediscovered' the technique, stated in 2003 that TDD
encourages simple designs and inspires confidence.
Test-driven development cycle
1. Add a test
2. Run all tests and see if the new one fails
3. Write some code
4. Run tests
5. Refactor code
Keep the unit small
For TDD, a unit is most commonly defined as a class, or a
group of related functions often called a module. Keeping
units relatively small is claimed to provide critical benefits,
including:Described in detail in "The Art of Software
Testing" (1979) by Glenford Myers.
Reduced debugging effort – when test failures are
detected, having smaller units aids in tracking down
Self-documenting tests – small test cases are easier to
read and to understand.
Effective layout of a test case ensures all required actions
are completed, improves the readability of the test case,
and smooths the flow of execution.
Individual best practices
Separate common set up and teardown logic into test
support services utilized by the appropriate test cases.
Keep each test oracle focused on only the results
necessary to validate its test.
Design time-related tests to allow tolerance for execution
in non-real time operating systems.
Treat your test code with the same respect as your
production code. It also must work correctly for both
positive and negative cases, last a long time, and be
readable and maintainable.
Practices to avoid
Having test cases depend on system state manipulated
from previously executed test cases.
Dependencies between test cases. A test suite where
test cases are dependent upon each other is brittle and
Testing precise execution behavior timing or
Building “all-knowing oracles.” An oracle that inspects
more than necessary is more expensive and brittle over
Behavior-driven development (BDD)
Software development process that emerged from TDD.
Behavior-driven development combines the general
techniques and principles of TDD with ideas from domain-
driven design and object-oriented analysis and design to
provide software development and management teams
with shared tools and a shared process to collaborate on
What’s wrong with TDD?
Behavior-driven development was developed by Dan North
as a response to the issues encountered teaching test-
Where to start in the process
What to test and what not to test
How much to test in one go
What to call the tests
How to understand why a test fails
Unit test names be whole sentences starting with the
word "should" and should be written in order of business
Acceptance tests should be written using the standard
agile framework of a User story: "As a [role] I want
[feature] so that [benefit]".
Acceptance criteria should be written in terms of
scenarios and implemented as classes: Given [initial
context], when [event occurs], then [ensure some