This repo is to practice the book Test Driven Development: By Example (Kent Beck) in Scala.
sbt test
Watch the tests:
sbt
sbt> ~test
There are certainly programming tasks that can't be driven primarily by tests (or at least, not yet). Security software and concurrency, for example, are two topics where TDD has no obvious application. The ability to write concrete, deterministic, automated tests is a prerequisite for applying TDD.
For the vast majority of us in between, though, following these two simple rules can lead us to work much closer to our potential:
- Always write a failing automated test before you write any code
- Always remove duplication
We'll make a to-do list to remind us what all we need to do, keep us focused, and tell us when we are finished.
We don't start with objects, we start with tests.
Start small or not at all.
The TDD cycle is:
- Write a test
- Make it compile
- Make it run
- Remove duplication
The tests must be:
- Easy to write for programmers
- Easy to read for programmers
- Quick to execute - If the tests don’t run fast, they won’t get run. If they don’t get run, they won’t be valuable. If they aren’t valuable, they won’t continue to be written.
- Order independent
- Deterministic
- Piecemeal - We'd like to be able to write the tests a few at a time
- Composable
- Versionable
- A prioi - We should be able to write the tests before they can possibly run
- Automatic - The tests should run without human intervention
- Helpful when thinking about design - Writing the tests a priori should be a learning experience