When we are working on tests exercising large parts of our software system (e.g. in an acceptance test suite), we often have to set up a considerable amount of data to set the stage for the scenario under test. This might include several calls to cumbersome APIs. At first, such code can be hard do get right. When it is working properly, many times the intention of the setup is greatly hidden in a convoluted mess of code. Therefore, such code can pose a major hurdle for the evolution of the project. Although intensive refactoring can provide benefits, there are things demanding even better readability. At this point, techniques, patterns and tools like Specflow can provide advantages. In this talk we discuss typical problems faced with the setup of test data and means to address those. We illustrate three cases where non-trivial setup was needed. After understanding the challenges faced we will present and discuss the final solutions. All topics are supported by code examples from a 10+ year project that has faced all of those issues.

1. www.techtalk.at
Setting up Complex Scenarios for Automated Tests
Paul Rohorzka
Software Gardener
February 22nd, 2017
Seeding a Tree in a Gherkin
@paulroho
pro@techtalk.at

2. 2
What's Your Occupation?
?

3. 3
What is
right?
Make it
right
Is it
right?
Requirements Engineer
Product Owner
Developer
Tester
QA
PM
Testautomation Engineer
Architect

4. 4
Arrange
Act
Assert
Setup
Execute
Verify
What is right? Make it right Is it right?
Given
When
Then
By original uploader: Roke - Own work, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=31996181

5. 5
Setup
Execute
Verify
Given
When
Then
Arrange
Act
Assert
Three Parts of an
Automated Test What is the
scenario?
What should trigger
the behaviour?
Important question:
How are they
related?
Can I actually observe
what I expected?

6. 6
Example: Unit Level
GetFormattedValue
value
format
(return)

7. 7
Same With Acceptance/End-to-End?
IN
OUT

8. 8
Setup
Check
This talk
... and a little bit ...
It's Often Like This

9. 9
So Much Information!

10. 10
What Are My Options?

11. 11
 Can feel clean (???)
 Hidden Setup
 Incomplete Scenario
 Obscuring important parts
 Dependencies
 State?!
 What if scaling out?
Classical Option 1: Common Test Data Set
Data B
Data C
Data A
Data Y
Data X
Data Z
Test 2
Test 3
Test 1
Test 98
Test 97
Test 99
Code, Database, File, ...

12. 12
 Easy to get via refactoring
 Gets quickly out of hand (overloads, optional parameters, ...)
Classical Option 2: Setup Method

13. 13
 Can be easily extended (as domain grows)
 IDE can help (Intellisense)
 Initial effort
 Needing multiple parts of complex structure
Classical Option 3: Builders

14. 14
Taking Builders Further

15. 15
No Matter What – Think of the Reader!
What would we
like to read?
Write it down!
Do we like it?
Fix the syntax!
Do we still like it?
Make it work!
Imagine Engage Accomplish

16. 16
Use whatever works best
for the people involved
https://flic.kr/p/47xDKh

17. It's Showtime!
https://flic.kr/p/aN2zDe

18. Act 1:
Specifying a C# API

19. Structure of an Organization
"Org Units"

20. 20
Specifying the InfoManager API
InfoManager
Client
C#
API
Specs

21. 21
The Obvious Approach:
Unit Tests

22. 22
The Obvious Approach:
Unit Tests

23. 23
• Where is the code under test?
• How let the spec stand out from other low-level unit tests?
• The client app's developer is the user of your API
• The interface might be subject of a conversation
• It defines the behaviour (i.e. more than the static contract)
 Give Gherkin a try!
Considerations

24. 24
Interlude: The Gherkin Language
Given
When
Then

25. 25
Connecting Gherkin With Code
"Step Bindings"

26. 27
Our Take – The Specs

27. 28
Our Take – One More

28. 29
• Bindings might get increasingly messy
• Refactoring can make the specs wrong
Some Downsides

29. 30

30. Act 2:
Building a Permission
Chain
https://flic.kr/p/4SxU1r

31. Introducing PERSY
(PERmission SYstem)
• 6 chained objects
• Each active/inactive
• Ignore chain if one object is inactive
User Position
AD-Group
Groupm:n m:n

32. 33
Setup in 6 one-liners?

33. 34
Super-Entity
to the rescue!
https://flic.kr/p/eXQbXV

34. 35
Super entity PermissionChain
User Position
AD-Group
Groupm:n m:n
PermissionChain

35. 36
PermissionChainBuilder in Action

36. 37
Stress your imagination!

37. 38
String Representation in Unit Testing Style

38. 39
Utilizing Gherkin Style
Syntax
highlighting
Variations:

39. 40
The Catch
Fragile!
 Meta tests
Is it worth it?
Yes, if this is part of
the core domain
1 out of 50+!

40. 41
A Meta Test

41. 42

42. Act 3:
Seeding A Tree
https://flic.kr/p/ooBmLt

43. 44
Testing a Feature Based on a Tree Structure
"Org Units"

44. 45
In the Database

45. 46
Obvious Approach: Domain Model API

46. 47
Next Attempt: Builders

47. 48
Going Meta: Meta-Builder

48. 49
Switching to Gherkin

49. 50
Away With the Parent References

50. 51
Away With That Many Columns

51. 52
Away With the Table

52. 53
Away With the Dots

53. 54
Some ASCII Art

54. 55


55. 56
Is It Worth The Trouble?
ReadabilityEase of Usage
Effort of
Implementation
Living
Documentation
maintain
extend
discover
edit

56. 57
Build
ReflectDecide
Hint: Iterate!
Don't try to build
too much magic
up front!

57. 58
Put First
What You Would Love to See
Not What You Have.
By Mstyslav Chernov - Self-photographed, http://mstyslav-chernov.com/, CC
BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=28541140

58. 59
Thank You!
Your Thoughts?

59. 60