TDD for WS Engineering Delivery

Another "introduction to TDD" talk for work

Transcript

1. Test-driven development Kerry Buckley 15 July 2013
2. Who the hell are you?
3. What is TDD?
4. Test-driven development From Wikipedia, the free encyclopedia 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 From Wikipedia, the free encyclopedia 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 From Wikipedia, the free encyclopedia 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 From Wikipedia, the free encyclopedia 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. Test-driven development From Wikipedia, the free encyclopedia 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.
9. Test-driven development From Wikipedia, the free encyclopedia 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.
10. 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 account_1.balance.should eq(80) account_2.balance.should eq(70) ➊ Arrange ➋ Act ➌ Assert
11. Types of test
12. Acceptance tests System Test
13. Acceptance tests Feature: Request the running of a night audit report Scenario: Requesting a Night Audit Report Given I am logged in And CRM is ready to run night audit When I request a night audit report Then the night audit report should be run Scenario: Requesting another report while one is queued Given I am logged in And I have already pressed the night audit button When I request a night audit report Then it should tell me that the report is already queued Scenario: [etc...]
14. Acceptance tests Feature: Request the running of a night audit report Scenario: Requesting a Night Audit Report Given I am logged in And CRM is ready to run night audit When I request a night audit report Then the night audit report should be run Scenario: Requesting another report while one is queued Given I am logged in And I have already pressed the night audit button When I request a night audit report Then it should tell me that the report is already queued Scenario: [etc...]
15. Acceptance tests When "I request a night audit report" do click_link "Night Audit Reports" click_button "run report" end
16. Integrated tests Test Test
17. Unit tests Test Mock Mock Test Mock
18. Unit tests describe VlanGroup, :database do describe ".with_name" do context "when there is no group with the same name" do it "returns a new record" do expect(VlanGroup.with_name "foo").to eq VlanGroup.new(name: "foo") end end context "when there is a group with the same name" do let!(:vlan_group) { VlanGroup.create name: "foo", device_count: 1 } it "returns it" do expect(VlanGroup.with_name "foo").to eq vlan_group end end end end
19. Unit tests $ rspec -f s spec/unit/models/vlan_group_spec.rb VlanGroup .with_name when there is no group with the same name returns a new record when there is a group with the same name returns it Finished in 0.17416 seconds 2 examples, 0 failures
20. Unit tests $ rspec -f s spec/unit/models/vlan_group_spec.rb VlanGroup .with_name when there is no group with the same name returns a new record (FAILED - 1) when there is a group with the same name returns it Failures: 1) VlanGroup.with_name when there is no group with the same name returns a new record Failure/Error: expect(VlanGroup.with_name "foo").to eq VlanGroup.new(name: "foo") expected: #<VlanGroup @name="foo" @device_count=nil @url=nil> got: nil (compared using ==) # ./spec/unit/models/vlan_group_spec.rb:8:in `block (4 levels) in <top (required)>' # ./spec/support/database_hooks.rb:10:in `block (2 levels) in <top (required)>' Finished in 0.17733 seconds 2 examples, 1 failure
21. Towards TDD 0. manual testing Write code Release Design Test
22. Towards TDD 1. automated testing Write code Write tests Release Design Test
23. Towards TDD 2. test-first development Write tests Write code Release Design Test
24. Design Towards TDD 3. test-driven development Write test Write code Release Run test Run tests Refactor
25. Towards TDD 3. test-driven development Red Refactor Green
26. Three laws of TDD
27. Three laws of TDD 1. Do not write any production code unless it is to make a failing unit test pass
28. Three laws of TDD 1. Do not write any production code unless it is to make a failing unit test pass 2. Do not write any more of a unit test than is sufficient to fail (compilation errors count!)
29. Three laws of TDD 1. Do not write any production code unless it is to make a failing unit test pass 2. Do not write any more of a unit test than is sufficient to fail (compilation errors count!) 3. Do not write any more production code than is sufficient to pass the one failing unit test
30. Beyond TDD? 4. behaviour-driven development Red Refactor Green Executable examples Release TDD Customer
31. A good test…
32. A good test… • Expresses the programmer’s intent
33. A good test… • Expresses the programmer’s intent • Gives confidence that the code works
34. A good test… • Expresses the programmer’s intent • Gives confidence that the code works • Only tests one thing
35. A good test… • Expresses the programmer’s intent • Gives confidence that the code works • Only tests one thing • Gives clear failure messages
36. 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
37. A good test suite…
38. A good test suite… • Gives confidence that the system works
39. A good test suite… • Gives confidence that the system works • Runs quickly
40. A good test suite… • Gives confidence that the system works • Runs quickly • Is well-maintained
41. A good test suite… • Gives confidence that the system works • Runs quickly • Is well-maintained • Isolates each area under test
42. Benefits for developers
43. Benefits for developers • Less manual testing required
44. Benefits for developers • Less manual testing required • Faster feedback
45. Benefits for developers • Less manual testing required • Faster feedback • ‘Safety net’ when making changes
46. Benefits for developers • Less manual testing required • Faster feedback • ‘Safety net’ when making changes • Improved design
47. Benefits for developers • Less manual testing required • Faster feedback • ‘Safety net’ when making changes • Improved design • Less code
48. Benefits for developers • Less manual testing required • Faster feedback • ‘Safety net’ when making changes • Improved design • Less code • Executable documentation
49. Benefits for business
50. Benefits for business • Acceptance tests clarify understanding
51. Benefits for business • Acceptance tests clarify understanding • Frees QA teams for exploratory testing
52. Benefits for business • Acceptance tests clarify understanding • Frees QA teams for exploratory testing • Shorter cycle time
53. Benefits for business • Acceptance tests clarify understanding • Frees QA teams for exploratory testing • Shorter cycle time • Fewer bugs
54. Benefits for business • Acceptance tests clarify understanding • Frees QA teams for exploratory testing • Shorter cycle time • Fewer bugs • Reduced rework
55. How do I start?
56. How do I start? • Greenfield project? JFDI! Otherwise…
57. How do I start? • Greenfield project? JFDI! Otherwise… • Automate highest value tests first
58. How do I start? • Greenfield project? JFDI! Otherwise… • Automate highest value tests first • Important features
59. How do I start? • Greenfield project? JFDI! Otherwise… • Automate highest value tests first • Important features • Where the most bugs occur
60. 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
61. 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
62. Warnings
63. Warnings • TDD is hard
64. Warnings • TDD is hard • Don’t start learning on production code
65. Warnings • TDD is hard • Don’t start learning on production code • Don’t forget to refactor
66. Warnings • TDD is hard • Don’t start learning on production code • Don’t forget to refactor • Look after your tests
67. Warnings • TDD is hard • Don’t start learning on production code • Don’t forget to refactor • Look after your tests • You can’t force people to do it
68. Warnings • TDD is hard • Don’t start learning on production code • Don’t forget to refactor • Look after your tests • You can’t force people to do it • Metrics lie
69. Further reading
70. Questions & Discussion