The presentation describes testing techniques which have been successfully applied in commercial Scala projects.

1. Testing Practicies not
only in Scala
by Paweł Panasewicz
pawel.panasewicz(at)gmail.com
@pawelpanasewicz
github.com/PawelPanasewicz
... actually ...
ScaLAB Conference, 2016 Wrocław
1

2. Who am I
Professionally for > 10 years in Software Development
mostly in commercial projects
Impressed by Scala Language and Functional Approach
In free time
engaged in Music Production
learning about Artificial Intelligence
like to ride bicycle
2

3. Prologue
3

4. The Analyst
val analyst = //there was an analyst
Analyst(whatLearnt = Set()) //at the beginning he knew not a lot
.copy(whatLearnt = Set(UML, SQL, XML)) //but in time he's achieved skills
analyst
.changeYear(_ + 5) //... few years later
.`are my skills still up to date` //?
//👍 All Skills Up To Date
4

5. The Project Manager
val manager = //there was a project manager
ProjectManager(whatLearnt = Set()) //at the beginning he knew not a lot
.copy(whatLearnt = Set(GantChart,
ManagingStyles.visionary, WritingSolemnEmails,
ManagingStyles.commanding)
) //but in time he's achieved skills
manager
.changeYear(_ + 5) //... few years later
.`are my skills still up to date` //?
//👍 All Skills Up To Date
5

6. The Software Developer
val developer = //there was a software developer
Developer(whatLearnt = Set()) //at the beginning he knew not a lot
.copy(whatLearnt = Set(
Slick1, Slick2, Spray1, Angular1, play1,
`play < 2.5`, `your favourite example of not to old tech`
)) //intelligent beast has learnt a lot
developer
.changeYear(_ + 5) //... few years later
.`are my skills still up to date` //?
// 😕 Well Not Really
6

7. So what?
The best-before date of IT technologies are often short space of
time
As good Software Developer you have to frequently update your
skills
It would be nice if there were some areas which don't change so
rapidly
because you could successfully take advantages of them for long
time
Well, there are such areas and among them:
Design Patterns
Software Development Philosophies
Shortcuts in Intellij and Vim
Testing 😎
7

8. Agenda
Why to test code?
What code testing is all about?
Good practicies
8

9. in order to deliver high quality sofware and be safe
Why
In general
to test code?
9

10. Why
In particular
to test code?
to demonstrate that the software satisfies its
specification
to find bugs during development phase, not
during production run
to be safe when refactoring - tests will notify me
when introducing regression errors
10

11. I want to show the estimation of work done - there is as much progress as many test
scenarios in code base
I want to document how my codes and whole system works - it's helpfull not only for
other devs but as well managers, analysts and users.
TDD techniques guide mu during development
ATDD techniques make sure system does what business/users/analysts needs
I want to report performance of my application
I want to repair system because of the bug on production - first I develop the failing
test which reprodces the error, next I can fix it
I am just a prone to make mistakes human
many other factors inlcuding ~120 Mega results from google.com:
https://www.google.com/?gfe_rd=cr&gws_rd=cr&fg=1#q=why+to+test+software
In particular
Why
to test code?
11

12. What
is code testing all about?
In particular
12

13. Piece of code
Piece of code
consists of / forms
0..n
1
definition
13

14. Unit & Integration tests
what are?
code code code code code ... code code code code code
these kind of codes are tested by
integration tests
these kind of codes are tested
by unit tests
one big
integrated
code
perfect
undivided
unit of code
E2E, System Tests
Acceptance, Functional, UI
API Tests
Component,
Isolated UI,
Just Unit Test
- tests are performed when application is deployed on environment
- tests are performed during builds and development
14

15. they test if many components
cooperate well together
by developers not only to
developers
slower
they test behaviour of relative
small pieces of code in
isolation
by developers to developers
easy to test many scenarios
and hunt a bug
fast
mocking
Acceptance/Functinal testsUnit tests
Unit vs Functional
tests
15

16. ensure that app works
according to business
requirements (whatever the
implementation is)
do assure that developer's
design is in accordance with
business requirements
functionality guards
more parts together then less
worries
ensure that piece of code
works according to developer's
design
do not assure that developer's
design is in accordance with
business requirements
it's often silently assumed that
mocked dependecies will
behave in particular way which
is dangerous 'cuz unit tests will
not cover that
when designing new functionality
Unit vs Functional
Acceptance/Functinal testsUnit tests
16

17. Plan of attack
when delivering new functionality
1. Start from basic acceptance tests
2. Keep on refactoring
3. When requirements and architecture stops evolving hunt for
bugs using extensive Unit Tests
17

18. Good Practicies
advices when testing
18

19. Develop Calendar Service
CS must decide if particular day is
a working day or a holiday
API exposed in rest-like form
The Calendar Service
Example
BTW There are two
devs delegeted to
this task
19

20. Let's assume that we are using , and somehow there are imported testing goodies like HttpClient and nextFreePort() ...ScalaTest
First
small happy path acceptance scenario
20

21. Test Run
failed red
21

22. Implementation
as simple as needed
keybord is swapped and second developer is making
implementation whereas the first one is observing
(no slide with code with correct implementation, sorry
for that)
22

23. green
Test re-run
once again
great success !
23

24. Mondays are working days
more happy paths
keybord is swapped, the second dev is observing now
new testcases (still happy paths) are made
24

25. red
Test re-run
once again
25

26. Implementation
without extra features
keybord is swapped and second developer is making
implementation whereas the first one is observing
(no slide with code with correct implementation, sorry
for that)
26

27. red
Test re-run
and regression error found
ooopps, something went wrong ...
REGRESSION ERROR introduced
Tests are for rescue 😎
27

28. Implementation
and debugging
keybord is swapped and second developer is making
implementation whereas the first one is observing
28

29. red
Test re-run
all green
29

30. Refactoring
optimise readability, make it beautiful
"table of
contents"
private guts
in
descendent
order of
importance
30

31. red
Test re-run
all green
31

32. Quiz
Which "design patterns" have you noticed here?
Make it testable - the most important
TDD (or even ATDD or BDD)
Red Green Refactor
Happy Path first
Important goes up
Pair Programming
Baby steps
almost like a "pure function"
KISS
32

33. The Calendar Service
new requirements
different clients of CS have
different working days
default functionality must be
preserved
33

34. Meet the Table
and put test cases in such form
easy to create new test cases
easy to read
34

35. "Table of contents"
still in front of spec
and test routine may look like this:
35

36. Quiz
Which new "design patterns" have you noticed
here?
Table Driven Testing
36

37. The Calendar Service
new requirements
it must be documented
documentation must be
always up to date
37

38. Documenting
the functionality
38

39. Under the hood
it's just simple HTML
extra html attributes
part of resources
39

40. Executing Spec
is performed during tests
Html document can be parsed
Extra HTML attribues can help in that
Extracted values can be seen as:
and can be used to generate many testcases
which can be used for testing
40

41. Spec output
after test run
green - tests succeded
red - tests failed
41

42. Quiz
Which new "design patterns" have you noticed
here?
Executable Spec (Living Documentation)
42

43. Living Documentation
closer look at
Engage [developers] with your users
Create a shared domain language
Build mutually-understood delivery contracts
Describe the system concisely, so that errors and redundancy are
easily visible
Write living documentation: always coupled to the actual behaviour
of the system
- Chris Agmen Smith - autor of Petswood
- scala framework for it
- Free ebook
Petswood
Living doumentation
43

44. The Calendar Service
new requirements
web page
44

45. Project of web page
functionality
Choose system, provide date string, click submit. There
should appear message "working day" or "holiday" in
gray area. (sorry for typos)
45

46. Test routine
could look like this
it's ugly, unreadable
46

47. Abstract
over it
create high level API for manipulating the page
API can contain assertions (checkThatContains)
API can be reused
nicely explains what the test does
47

48. Quiz
Which design pattern have you noticed here?
Window Driver
48

49. Other techniques
handy when testing
49

50. Bob Snaphot's
technique
record input and output and use this data for testing
if actual output during tests differs from recorded that means
that regression errors were introduced
save output to files when test run and use diff tool for fast spot
differences
use it
when you don't really know what right behaviour/ouptut
should be
only subject expert matter can decide if behaviour is fine
when you render something
50

51. More test code lines
then production code lines
It's good sign
measure it
51

52. howitworks
package
use it as playground when learning something new which might
be used in project
easy to copy/paste working solution
easy to remove when not needed or disturbing
often better then stackoverflow
52

53. Domain Test Data in one place
good practice
test data builders and factories
example data in one place
even identifiers of rows id DB and their values
understanding domain data is key to understand what system is
supposed to do
53

54. That's it
Thank you!
Questions?
54