Test Driven chapter 1

Går igenom grunderna i TDD. Några intressanta saker:

"Only ever write code to fix a failing test"
Motivering
- Late defects are expensive
- Quality, (good design, no duplication, etc)
- Specification is time consuming, get old fast - TDD delivers
- Test first --> Design "inner API"

Test-->Code-->Refactor

Without refactor we have well tested BAD code.
You cannot get the architecture right on the first try
The human brain can fit 5-7 concepts simultaneosly in working memory

Refactoring preserves behaviour
Regression is existing, once-working functionality getting broken
Tests are an integral part of requirements and specification
Tests as specification
- A LOT faster feedback through automatino
- More reliable test exedcution
- One less translation step

Tools
xUnit
Fit and Fitnesse
Continuous integration - http://www.martinfowler.com/articles/continuousIntegration.html
Lint - www.splint.org
PMD - pmd.sf.net
code coverage - http://www.javaranch.com/newsletter/200401/IntroToCodeCoverage.html

Questions
How do you know it's the right test and not an unnecessary one?
Are there a paper on stated fact that Evolutionary design is less expensive than trying to get the final design on paper in the beginning?
How do ATDD trace onto TDD?
Difference btw user stories vs use cases?