Adopting tdd in the workplace
0 likes160 views
The document outlines a practical approach to Test-Driven Development (TDD) in the workplace, emphasizing the importance of gathering requirements and using Gherkin language for defining behavior. It details steps for creating an effective test suite and highlights potential pitfalls, as well as strategies for testing existing code and scaling up tests. Lastly, it underscores the benefits of automated testing over manual efforts and encourages incremental improvements in testing practices.
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 workflows that stakeholders and testers are going to run • Refine your Gherkins Establish acceptance criteria
- 9. • Do a final check to see if all cases are covered • Check that errors are handled appropriately • Make sure that all Gherkins are unambiguous Review and refine
- 10. • Talk to stakeholders, understand their wants and needs • Formalize decisions, write down business rules using Gherkin and find edge cases • Establish acceptation criteria, what “tests” will the stakeholder run themselves once you deliver • Review and refine Gathering Requirements
- 11. Gherkin A human readable language to define 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 definition 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 different 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 different 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 prefix are your tests • Doesn’t lend itself to a Gherkin style of testing very well
- 47. Quick • A Behavior Driven Development testing framework • Different keywords to highlight different 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 define the Given
- 49. Context Quick: Can be used to describe the environment that a system exists in TDD: Can be used to define the When (the action)
- 50. It Quick: Used to group and do assertions, the “actual” test TDD: Used to define 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 first, 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 flow
- 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 different configurations • 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 first, 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