SNAPSHOT
TESTING
.. going beyond UI
June 2018
@berlinjs
Slide 2
Slide 2 text
WHAT IS THE ONE THING
THAT INFLUENCED MY PROFESSIONAL CARRIER?
Slide 3
Slide 3 text
TEST DRIVEN DEVELOPMENT
the only way to fix your fuckups before anybody else sees it.
Slide 4
Slide 4 text
Alexander Beletsky
Ph.D, Software Engineer, Lead Architect at blogfoster GmbH
http://beletsky.net
https://github.com/alexbeletsky
@alexbeletsky
Slide 5
Slide 5 text
YOU HEARD
ABOUT JEST, RIGHT?
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
LONG, LONG
TIME AGO…
Slide 8
Slide 8 text
APPROVAL
TESTING
one of the first implementations snapshot testing with nicer UX.
by Llewellyn Falco
Slide 9
Slide 9 text
COMPUTERS
are great with
COMPUTATION
Slide 10
Slide 10 text
HUMANS
are great with
RECOGNITION
Slide 11
Slide 11 text
Let the machine perform the
computation, but leave a human to
make a decision if this computation
is right.
Slide 12
Slide 12 text
THE
CONCEPT
Slide 13
Slide 13 text
It all comes to understanding the
state of the system and the
representation of this state (output
of system).
Slide 14
Slide 14 text
STATE REPRESENTATION
front-end people
In case of Redux-based applications, the state is actual
Redux state. For else, it’s typically set of models.
The UI rendered by Browser (HTML / CSS / JS)
Slide 15
Slide 15 text
STATE REPRESENTATION
back-end people
Any kind of database and server business logic that
process the data
JSON / HTML / XML (or any other) Server response
Slide 16
Slide 16 text
STATE REPRESENTATION
mobile people
The model or set of models, initialized from server or
local storages
The UI rendered by mobile platform (iOS, Android)
Slide 17
Slide 17 text
The most important to make the
concept work, is being able to
“freeze” the state and get the as full
as representation of the system as
possible.
Slide 18
Slide 18 text
const R = f (State);
expect(R.serialize()).toMatchSnapshot();
* the only 2 lines of code in this presentation
** and yes, I’m using semicolons in JS
Slide 19
Slide 19 text
The representation of the system’s
state should be serialized into some
appropriate format, could be
anything that satisfies couple of
properties..
Slide 20
Slide 20 text
It should be,
Diffable
for machines
so if there is change between two different snapshots, the machine able to detect difference.
Slide 21
Slide 21 text
It should be,
Readable
for humans
so if there is change occurred, human is able to understand it and say if it’s right or not
Slide 22
Slide 22 text
THE
PRACTICE
Slide 23
Slide 23 text
Once upon a time,
at work..
Slide 24
Slide 24 text
COMBINATORIAL
COMPLEXITY
of testing
too many parameters, too many combinations of tests to cover a case.
Slide 25
Slide 25 text
… With HTML and many combinations, asserts didn’t work
Slide 26
Slide 26 text
STATE REPRESENTATION
MongoDB with `.invoices` collection to store invoices
documents + incoming query parameters
HTML/PDF of the invoice, served by
/v1/invoices/{id}.html endpoint
/v1/invoices/447.html?lang=de
+
Slide 27
Slide 27 text
transform all possible combinations and validate them “manually”.