Adopting tdd in the workplace
0 likes5,033 views
The document outlines a practical approach to Test-Driven Development (TDD) in the workplace, emphasizing the importance of gathering requirements and utilizing Gherkin for test case formulation. It provides a step-by-step guide to implementing tests, highlighting the need for gradual refactoring and building up test coverage. The conclusion stresses that automated testing is significantly more efficient than manual testing.
Adopting tdd in the workplace
- 2. A Practical Approach to TDD in the Workplace
- 3. âA developer who doesnât write enough tests âYeah, I think this feature works.â
- 4. Todayâs goals âą Understand how to build a quality test suite. âą Learn how to start testing in existing projects. âą Understand why a good test suite doesnât cost (a lot of) extra development time.
- 5. Before you write your tests You must gather requirements
- 6. âą Your stakeholders are pretty much anybody who can and will talk to you about product requirements âą Donât expect your stakeholders to give your their requirements clear and concise âą Try to understand the wants and needs of your stakeholders rather than taking whatever they say at face value âą Product owners and project managers should help you out Talk to stakeholders
- 7. âą Write down all requirements, these decisions are the foundation for your tests âą For every business rule and requirement you determine, search edge cases âą A language framework like Gherkin is helpful in this phase (more on Gherkin later) Formalize decisions
- 8. âą Find out when the work is âdoneâ âą Figure out the manual tests and workïŹows that stakeholders and testers are going to run âą ReïŹne your Gherkins Establish acceptance criteria
- 9. âą Do a ïŹnal check to see if all cases are covered âą Check that errors are handled appropriately âą Make sure that all Gherkins are unambiguous Review and reïŹne
- 10. âą Talk to stakeholders, understand their wants and needs âą Formalize decisions, write down business rules using Gherkin and ïŹnd edge cases âą Establish acceptation criteria, what âtestsâ will the stakeholder run themselves once you deliver âą Review and reïŹne Gathering Requirements
- 11. Gherkin A human readable language to deïŹne behavior
- 13. Feature Provides a high level overview of a software feature, and to group related scenarios.
- 14. Scenario Brief description, used to provide context for the test that it applies to.
- 15. Given The initial state of the described test. Something that has already happened or is ongoing.
- 16. When The user input or system change that is tested. A scenario should typically only be concerned with a single action, earlier actions than the ones you care about should either be given or part of the scenario.
- 17. Then Describes the state of the system after it has been manipulated by the action (When). Should only be used to assert that the system is (eventually) in the expected state.
- 18. Whatâs good about this âą Gherkin provides a solid foundation âą Leads to much better understanding of the system âą Much easier to discover missed cases and edge cases
- 19. Potential pitfalls âą Not always easy to get stakeholder buy-in âą Never assume that your Gherkins are complete âą Donât take the deïŹnition phase to literally âą Stakeholders often donât concern themselves with the deep internals of a system
- 20. TDD Weâre close to seeing some actual tests, I promise
- 21. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 22. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 23. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 24. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 25. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 26. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 27. A Quick Primer on TDD Repeat STEP 4 A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 28. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 29. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 30. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 31. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 32. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 33. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 34. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 35. Tested âą We can create an instance of LoginForm âą LoginForm.login() throws âą LoginForm.username is optional and nil by default âą LoginForm.password is optional and nil by default âą LoginForm.login() does not throw when username and password are present âą LoginForm.login() throws a diïŹerent error when username or password is missing âą We can set a username or password on LoginForm âą And more⊠Not tested
- 36. đ TDD âą All the code you write is tested âą It provides a structured way to think about a problem âą You canât write untestable code âą Can take a lot of time âą Youâre allowed to blame the Swift compiler for that âą It feels silly to knowingly write tests that canât pass for trivial things âą It can feel somewhat limiting when you just start out đ TDD
- 37. The way I like to do TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 38. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 39. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 40. A Quick Primer on TDD A Failing Test STEP 1 Write the minimal amount of code needed to make the test pass STEP 2 A Passing Test STEP 3 Repeat STEP 4
- 41. Tested âą We can create an instance of LoginForm âą LoginForm.login() throws âą LoginForm.username is optional and nil by default âą LoginForm.password is optional and nil by default âą LoginForm.login() does not throw when username and password are present âą LoginForm.login() throws a diïŹerent error when username or password is missing âą We can set a username or password on LoginForm âą And more⊠Not tested
- 42. To Xcode Itâs time to write some tests
- 43. File -> new -> Unit Test File
- 45. XCTest âą Xcodeâs default testing framework âą Methods with the test preïŹx are your tests âą Doesnât lend itself to a Gherkin style of testing very well
- 47. Quick âą A Behavior Driven Development testing framework âą DiïŹerent keywords to highlight diïŹerent parts of your tests âą Is very suitable for Gherkin style testing
- 48. Describe Quick: Can be used to describe the system thatâs being tested. TDD: Can be used the deïŹne the Given
- 49. Context Quick: Can be used to describe the environment that a system exists in TDD: Can be used to deïŹne the When (the action)
- 50. It Quick: Used to group and do assertions, the âactualâ test TDD: Used to deïŹne the Then and do assertions
- 51. Important âą Quick was not really meant to be used as I just demonstrated âą Nevertheless, this works for me
- 52. Letâs implement a test!
- 53. Step 1 - Create login form
- 54. Step 2 - Perform action
- 55. Step 3 - Assert results
- 56. Remember the XCTest version?
- 59. Testing existing code AKA the big refactor
- 60. Phase one: Preparation âą You canât build an amazing test suite overnight âą You can, however, begin refactoring your code âą And of course, write tests for any new features
- 63. Phase one: Preparation After LoginService Abstracts the networking logic using a protocol so it can be mocked in a test.
- 64. Phase two: Start small âą Thereâs no point in trying to test everything all at once âą Avoid complex tests at ïŹrst, you might want to practice with simple tests
- 65. Phase two: Start small
- 66. Phase two: Start small MockLoginService A simple object that tracks whether its login method was called
- 67. Phase two: Start small Async assertion We assume that the login method does asynchronous work, the network call must eventually be made.
- 68. Phase three: Scale up âą Tackle more complex problems âą Expand your test cases âą Start thinking about integration tests
- 69. Getting time to test Convincing your manager
- 70. Letâs look at a login ïŹow
- 72. Inputs to test for email âą me@donnywals.com âą donny.wals@donnywals.com âą me@donnywals.co.uk âą invalid.com âą invalid@mail âą v.a.l.i.d@mail.com âą $1gnz@test.com âą And moreâŠ
- 73. And you need to do this on every screen
- 74. Inputs to test for registration âą First name: Donny, Last name: Wals âą First name: Donny, Last name: van Wals âą First name: The Donny, Last name: Wals âą First name: D.onny, Last name: Wals âą First name: Bobby, Last name: Tables âą And many moreâŠ
- 75. How long would it take you to test this?
- 76. Video
- 77. Taking it to the next level Extra credit!
- 78. Xcode 11âs test plans âą Test localizations (mostly for UI) âą Run tests with diïŹerent conïŹgurations âą Randomize test order
- 79. Run your tests on CI âą Running tests on every push to GitHub âą Automated testing on set intervals âą CI is the best way to make sure your tests are run
- 80. Summary âą Gathering requirements is vital to a good test suite âą Gherkin is a nice way to convert requirements to pseudo-tests âą Quick can be used to write very readable tests âą Begin refactoring a code base ïŹrst, then slowly build up test coverage and complexity âą Testing manually takes way more time than doing so automatically
- 81. Thank you Questions, compliments and feedback are welcome