www.techtalk.at

Add PictureSetting up Complex Scenarios for Automated Tests

Paul RohorzkaSoftware Gardener

February 22nd, 2017

Seeding a Tree in a Gherkin @paulroho pro@techtalk.at

In einem Gurkerleinen Baum pflanzen

2

What's Your Occupation?

Requirements Engineer?

Product Owner?

Developer?

Tester? QA?PM?

?

Testautomation Engineer?

Architect?

3

What is

right?Make it right

Is it right?

Requirements Engineer

Product Owner

DeveloperTester

QA

PM

Testautomation Engineer

Architect

4

Arrange

Act

Assert

Setup

Execute

Verify

What is right?

Make it right Is it right?

Given

When

ThenBy original uploader: Roke - Own work, CC BY-SA 3.0,

https://commons.wikimedia.org/w/index.php?curid=31996181

5

Setup

Execute

Verify

Given

When

Then

Arrange

Act

Assert

Three Parts of anAutomated Test What is the

scenario?

What should trigger the behaviour?

Important question:

How are they related?

Can I actually observe what I

expected?

6

Example: Unit Level

GetFormattedValuevalueformat

(return)

7

Same With Acceptance/End-to-End?

INOUT

8

Setup

Check

This talk

... and a little bit ...

It's Often Like This

9

So Much Information!

10

What Are My Options?

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

Easy to get via refactoring

Gets quickly out of hand (overloads, optional parameters, ...)

Classical Option 2: Setup Method

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

Taking Builders Further

15

No Matter What – Think of the Reader!

What would welike to read?

Write it down!

Do we like it?

Fix the syntax!

Do we still like it?

Make it work!

Imagine Engage Accom

plish

16

Use whatever works best for the people

involved

https://flic.kr/p/47xDKh

It's Showtime!

https://flic.kr/p/aN2zDe

Act 1:Specifying a C# API

Structure of an Organization

"Org Units"

20

Specifying the InfoManager API

InfoManager

Client

C#

APISpecs

21

The Obvious Approach:Unit Tests

22

The Obvious Approach:Unit Tests

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

Probierein Gurkerl!

24

Interlude: The Gherkin Language

Given

When

Then

25

Connecting Gherkin With Code

"Step Bindings"

27

Our Take – The Specs

28

Our Take – One More

29

• Bindings might get increasingly messy

• Refactoring can make the specs wrong

Some Downsides

30

EffortBenefit

Act 2:Building a PermissionChain

https://flic.kr/p/4SxU1r

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

33

Setup in 6 one-liners?

34

Super-Entityto the rescue!

https://flic.kr/p/eXQbXV

35

Super entity PermissionChain

User Position

AD-Group

Groupm:n m:n

PermissionChain

36

PermissionChainBuilder in Action

37

Stress your imagination!

38

String Representation in Unit Testing Style

39

Utilizing Gherkin Style

Syntax highlightingVariations:

40

The CatchFragile!

Meta tests

Is it worth it? Yes, if this is part of

the core domain

1 out of 50+!

41

A Meta Test

42

BenefitEffort

Act 3:Seeding A Tree

https://flic.kr/p/ooBmLt

44

Testing a Feature Based on a Tree Structure

"Org Units"

45

In the Database

46

Obvious Approach: Domain Model API

47

Next Attempt: Builders

48

Going Meta: Meta-Builder

49

Switching to Gherkin

50

Away With the Parent References

51

Away With That Many Columns

52

Away With the Table

53

Away With the Dots

54

Some ASCII Art

55

BenefitEffort

56

Is It Worth The Trouble?

ReadabilityEase of Usage

Effort of Implementatio

n

Living Documentatio

n

maintainextend

discover

edit

57

Build

Reflect

Decide

Hint: Iterate!

Don't try to build too much magic up front!

58

Put FirstWhat 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

59

Thank You!

Your Thoughts?

60