7. REFACTORING
- You are able to ship features faster,
without worrying about breaking previous
ones
- Goal: even you refactor most internals of
your app, you shouldn't have to change
test code
- Do NOT tie your tests too much to internal
knowledge. As an example, HTTP API is
most likely the least changing API
- If you find yourself maintaining tests every
time you change code, that's wrong!
8. Even if you don't test every case now,
you should setup tests so that writing
cases is easy in the future.
Don't leave test
setup for later
10. It means extra maintenance because you
"fake" another API
* Unless that's really, REALLY the only
viable option. Are you sure it is?
Don't fake
anything*
11. NO FAKING
- Do real HTTP requests against your
backend. Setup the server running locally
and test that.
- Have a real Postgres with test database,
have a real S3 test bucket etc.
- Try to replicate the real scenario as close
as possible
- You don't want to maintain compability to
any external API. You already have to
maintain the compability with your own
app's API - That is enough work and
trouble
12. I have found them to be the good in
practice.
Focus to
integration tests
13. INTEGRATION
- Integration tests usually don't know that
much about app internals so they are easy
to maintain even your internals change. I
have done very big refactors with
confidence thanks to integration tests
- They may take longer to run, but ... usually
they are still more pragmatic than e.g. unit
tests
14. It will reveal bugs like missing
dependencies in app configuration.
Have a CI server
also run tests
15. CONTINUOUS
INTEGRATION
- Good to run tests in a different
environment than yours
- It will do a "fresh install", which might
reveal some details
- Travis CI and Circle CI are good tools
16. You know they'll help you later. They will
save your ass when you need to suddenly
refactor a lot to do a new feature.
No excuses,
take this medicine
17. NO EXCUSES
- Quite a lot of people I've spoken with,
knows the value of testing, but just
somehow they convince themselves not to
write them
- Initial setup takes time, but it will save time
later - trust yourself.
- If you have bad experience of maintaining
tens of breaking tests, try to test from
higher layer to minimize maintenance
19. FRAMEWORK
INTERNALS
HTTP LAYER
CORE LOGIC
DATABASE
- Unwraps HTTP request
- Does basic validation. "Does it look
correct"
- Doesn’t know HTTP, simple input and
output
- Handles database transactions
- Minimal input parameters and outputs raw
data structures. Does not reveal storage
details to caller.
- Minimize the dependency to a
specific database if possible
SPLIT
RESPONSIBILITIES
24. IF YOU NEED MORE
FRAMEWORK
INTERNALS
HTTP LAYER
CORE LOGIC
DATABASE
If you have e.g. bank transactions in your
business logic, definitely test them. The good
layer would be "core logic" = business logic
layer. Even though they will tie the tests to
internal knowledge
25. // I HAVE SOME BLOG POSTS
https://medium.com/@kimmobrunfeldt/the-real-benefit-of-tdd-d2fdc9fc4ddf#.o62kgijna
https://medium.com/@kimmobrunfeldt/testing-for-startups-10732eb253e8#.o9jy8igti
https://medium.com/@kimmobrunfeldt/introduction-to-sauce-labs-3ad082fc7dd5#.u041fufej