Learn how to gather requirements and translate them into tests. Doing this helps you adopt a TDD style of developing.

1. Donny Wals
@donnywals
https://donnywals.com
🎸 🎓 #

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

61. Phase one: Preparation
Before

62. Phase one: Preparation
After

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