“Everything fails all the time”. True for every software project, especially for a large and complex JS project. In this session we are gonna explore testing and monitoring techniques to deliver and maintain a ReactJS + Redux application, and at the same time being able to go back to sleep without the fear that everything is gonna explode during the night.

1. How to push a ReactJS
application in production
and sleep better
Emanuele Rampichini Application Engineer @spreaker

2. So, you are
building a
large
ReactJS
single page
application...
2
● Do you need it?
● Are you sure?
● 100% Sure?
● I’m gonna ask it again...
● ARE YOU SURE?

3. SINGLE PAGE
APPLICATIONS ARE
COMPLEX
3

4. PnP® APPROACH
4

5. TESTING AND
MONITORING TO THE
RESCUE
5

6. Monitor your
ReactJS
application
in production
Monitoring your application in
production is crucial even if you don’t
write tests. The good news is that
nowadays is quite easy
6
● https://sentry.io
● https://newrelic.com
● https://trackjs.com

8. WHAT ABOUT
TESTING?
8

9. Let’s start by
defining
some testing
concepts...
Test families ordered from the
cheapest to the most expensive one.
Cost is a mix of write difficulty,
execution time, and maintenance
effort requested.
9
● Unit Tests
● Integration Tests (or midway)
● End 2 End Tests
● Manual Tests

10. LET’S SEE HOW TO FIT
THIS INSIDE A
REACT + REDUX APP

11. Useful tools
to do unit
testing in
ReactJs
11
● https://karma-runner.github.io/1
.0/index.html
● http://jasmine.github.io/
● http://phantomjs.org/
● Look for Karma + Webpack +
PhantomJS on google and you
are gonna find a lot of tutorials to
create your setup.

12. Unit testing a
reducer
function is a
piece of
cake... really!
We are just testing pure functions
(without side effects) in the form:
(State, Action) => State
These tests are very good to ensure
correctness of your state mutation
logic.
12

15. Unit testing
components
rendering
Given some props we want to ensure
the correctness of the rendered
output.
15
● https://facebook.github.io/react
/docs/test-utils.html
● Shallow Renderer
● https://github.com/sheepsteak
/react-shallow-testutils
● https://github.com/airbnb/enzy
me

21. Unit testing
components
behaviour
We want to ensure that when
something happens on our
component (lifecycle callbacks, clicks
etc...) the right action get dispatched
to our store.
21
● http://jasmine.github.io/2.0/intr
oduction.html#section-Spies
● Lifecycle: getMountedInstance()
● UI interaction: getOutput()

24. Unit testing
middlewares
and rich
actions
(thunk)
We want to ensure that a rich action
dispatches the right simple actions
in the right order to our store when
some preconditions are met.
24
● https://github.com/arnaudbenar
d/redux-mock-store
● http://jasmine.github.io/2.0/intr
oduction.html#section-Spies

27. Midway
testing
We want to test components only
mocking things at the lower level in
our architecture (ex. xhr request).
Every other piece is gonna be the
real application code.
27
● https://github.com/jasmine/jas
mine-ajax
● Setup can be tricky, ensures that
all the pieces are working well
together.

28. End 2 End
testing with
protractor
In that case we want to interact
directly with our application, we
ignore completely the fact that we
are testing a reactJS app. These tests
are quite slow to run, hard to
maintain and they require full control
of your backend data.
28
● http://www.protractortest.org/
● Expected Conditions
● browser.ignoreSynchronization=true

29. Manual
testing on
multiple
devices
These test are the most expensive
ones, still they are crucial. Be sure to
have as many real devices as you
can. Here are some tips:
29
● Build your own device wall
● Have a staging environment that
maps 1:1 the production one and
do internal testing.
● Adopt canary deployment
strategies

30. IT’S NOT HUGE BUT WE
BUILT IT...
30

31. A LOT OF TESTS TO
WRITE AND TO
MAINTAIN… NOT A LOT
OF TIME 31

32. ▫ It’s OK not to test everything
▫ At first you are gonna be super
slow, then you are gonna
improve. Training is crucial.
▫ If you don’t have time to
implement tests just take some
to write test definitions and
mark them as skipped. You can
add coverage when you have
slack time. (xdescribe, xit )

33. P.S. WE ARE HIRING,
IF YOU ARE INTERESTED
OR YOU JUST WANT A
T-SHIRT JUST PING ME

34. Thanks. EMANUELE RAMPICHINI
APPLICATION ENGINEER @spreaker
Get It Touch
emanuele.rampichini@spreaker.com
@emanuele_r