2014 Graduate Bootcamp: TDD

Not about testing!

Not talking about a release cycle here (days/weeks/months).
Fast cycle while we’re writing the code (seconds/minutes).

Important step!
Refactoring means improving the designwithout changing behaviour (eg removing duplicated code).
TDD allows you to design incrementally, while only implementing what’s needed.
Separate talk later.

“Traditional” process.
Looks linear, but problems will be found in design and implementation.

Reduce the amount of time it takes to test by automating.
From now on, whenever anyone says “test”, you can generally assume they mean “automated test”.

Writing the tests first forces us to think about what each piece of code has to do.
Still needs the design to have been decided up-front though.

Now we have that TDD loop.
Run tests first to make sure they fail correctly, with useful messages.

Definition of BDD has changed over time.

From Uncle Bob Martin
(that’s not one of the rules)

“Black box”. Does the whole system work as required?
Generally means testing through the user interface.
Tend to be slow, so you don’t want many of them.

Test classes along with their collaborators.
May hit things like databases.
Faster than system tests, but can still be slow.
Can be brittle – changes to a collaborator can break unrelated test.
Give confidence that things are wired together right.

Genuine unit tests – test a single class, with test doubles standing in for collaborators.
Fast and isolated.
We’ll cover test doubles tomorrow.

Generally acceptance tests are more likely to be system or integrated tests, but they don’t have to be (eg validation rules).

Fewer slow system tests at the top. Mostly fast unit tests.

Arrange/act/assert
Given/when/then
Ignore the syntax.

Name tests well.

No need for repetitive manual testing – can concentrate on exploratory testing.
You get used to assuming high test coverage – gives confidence.

Yes – at the small scale fo individual changes.
Much less debugging.
Vastly reduced design/test phases.

Transcript

1. Test-driven development
2. Test-driven development (according to Wikipedia) Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
3. Test-driven development (according to Wikipedia) Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
4. Test-driven development (according to Wikipedia) Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
5. Test-driven development (according to Wikipedia) Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
6. Test-driven development (according to Wikipedia) Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
7. Test-driven development (according to Wikipedia) Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
8. Towards TDD
   0. manual testing Write code Release Design Test
9. Towards TDD
   0. manual testing Write code Release Design Test
10. Towards TDD
    0. manual testing Write code Release Design Test
11. Towards TDD
    1. automated testing Write code Write tests Release Design Test
12. Towards TDD
    2. test-first development Write tests Write code Release Design Test
13. Design Towards TDD
    3. test-driven development Write test Write code Release Run
 test Run
 tests Refactor
14. The TDD cycle Red Refactor Green
15. Outer and inner loops
    ATDD or BDD (maybe) Red Refactor Green Executable examples Release Customer
16. Rules of TDD
17. Rules of TDD
18. Rules of TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
19. Rules of TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
20. Rules of TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
21. Types of test
22. System tests System Test
23. Integrated tests Test Test
24. Isolated tests Test Double Double Test Double
25. Acceptance tests Does the system behave as it should?
26. Acceptance tests Does the system behave as it should? Unit tests Do individual pieces work correctly?
27. The testing pyramid GUI Integrated Unit
28. Anatomy of a test
29. Anatomy of a test ➊ Arrange
30. Anatomy of a test # Given some test accounts account_1 = Account.new(100) account_2 = Account.new(50) ➊ Arrange
31. Anatomy of a test # Given some test accounts account_1 = Account.new(100) account_2 = Account.new(50) ➊ Arrange ➋ Act
32. Anatomy of a test # Given some test accounts account_1 = Account.new(100) account_2 = Account.new(50) # When I transfer money transfer(20, from: account_1,
 to: account_2) ➊ Arrange ➋ Act
33. Anatomy of a test # Given some test accounts account_1 = Account.new(100) account_2 = Account.new(50) # When I transfer money transfer(20, from: account_1,
 to: account_2) ➊ Arrange ➋ Act ➌ Assert
34. Anatomy of a test # Given some test accounts account_1 = Account.new(100) account_2 = Account.new(50) # When I transfer money transfer(20, from: account_1,
 to: account_2) # Then the balances should be updated expect(account_1.balance).to eq 80 expect(account_2.balance).to eq 70 ➊ Arrange ➋ Act ➌ Assert
35. A good test…
36. A good test… Expresses the programmer’s intent
37. A good test… Expresses the programmer’s intent Gives confidence that the code works
38. A good test… Expresses the programmer’s intent Gives confidence that the code works Only tests one thing
39. A good test… Expresses the programmer’s intent Gives confidence that the code works Only tests one thing Gives clear failure messages
40. A good test… Expresses the programmer’s intent Gives confidence that the code works Only tests one thing Gives clear failure messages Is independent of other tests
41. It’s not a unit test if…
42. It’s not a unit test if… It talks to the database
43. It’s not a unit test if… It talks to the database It communicates across the network
44. It’s not a unit test if… It talks to the database It communicates across the network It touches the file system or reads config info
45. It’s not a unit test if… It talks to the database It communicates across the network It touches the file system or reads config info It uses the current time or random numbers
46. It’s not a unit test if… It talks to the database It communicates across the network It touches the file system or reads config info It uses the current time or random numbers It depends on non-deterministic behaviour
47. It’s not a unit test if… It talks to the database It communicates across the network It touches the file system or reads config info It uses the current time or random numbers It depends on non-deterministic behaviour It can't run at the same time as other unit tests
48. It’s not a unit test if… It talks to the database It communicates across the network It touches the file system or reads config info It uses the current time or random numbers It depends on non-deterministic behaviour It can't run at the same time as other unit tests You have to modify your environment to run it
49. A good test suite…
50. A good test suite… Gives confidence that the system works
51. A good test suite… Gives confidence that the system works Runs quickly
52. A good test suite… Gives confidence that the system works Runs quickly Is well-maintained
53. A good test suite… Gives confidence that the system works Runs quickly Is well-maintained Isolates each area under test
54. Benefits of TDD
55. Benefits of TDD Less manual testing required
56. Benefits of TDD Less manual testing required Faster feedback
57. Benefits of TDD Less manual testing required Faster feedback Make it safe to change code
58. Benefits of TDD Less manual testing required Faster feedback Make it safe to change code Reduced rework and debugging
59. Benefits of TDD Less manual testing required Faster feedback Make it safe to change code Reduced rework and debugging Improved design
60. But isn’t it slower?
61. How do I start?
62. How do I start? Greenfield project? JFDI! Otherwise…
63. How do I start? Greenfield project? JFDI! Otherwise… Automate highest value tests first
64. How do I start? Greenfield project? JFDI! Otherwise… Automate highest value tests first Important features
65. How do I start? Greenfield project? JFDI! Otherwise… Automate highest value tests first Important features Where the most bugs occur
66. How do I start? Greenfield project? JFDI! Otherwise… Automate highest value tests first Important features Where the most bugs occur Use TDD for new features
67. How do I start? Greenfield project? JFDI! Otherwise… Automate highest value tests first Important features Where the most bugs occur Use TDD for new features Add tests for bugs when they’re found
68. How do I start? Greenfield project? JFDI! Otherwise… Automate highest value tests first Important features Where the most bugs occur Use TDD for new features Add tests for bugs when they’re found Practice!
69. Further reading