Clean Tests - Scala UA

TDD isn’t news, and most everyone agrees that writing tests (before, during or after implementation) is valuable. Hardly anyone agrees on what good, clean tests look like, though; if your tests are a live specification of your codebase, don’t they deserve the same care and attention as your production code?
This talk focuses on how to keep your tests readable, simple and maintainable. Specifically we will discuss how the “given-when-then” pattern affects the way you factor your code, and showcase the remarkable differences between a sloppy specification and a well-factored one.

Transcript

1. github.com/noam-almog
3. Why you should clean your tests ▪ ▪ ▪
4. “ “
5. What is “good”? ? ? ? D o o g a b
8. The structure is a Map to your code. Code Implementation
9. ★ ★ The MAP’S RATIO Show TOO MUCH Hide TOO MUCH
10. What are you testing? The Code The Code’s Behavior Show TOO MUCH Hide TOO MUCH
11. Can a single test Stand on its own? Yes No Show TOO MUCH Hide TOO MUCH
12. public void testCancel_notDoneInterrupt() throws Exception { Future<?> future = newFutureInstance(); future.cancel(true); try { future.get(); fail("Expected CancellationException"); } catch (CancellationException e) { assertNotNull(e.getCause()); } } 1. description 2. given 3. when 4. then Test structure
14. public void testCancel_notDoneInterrupt() throws Exception { … } Test description "throws an exception reducing a canceled future" "Sends an email to the server with the site-id"
15. Test Description does not compile. Don’t trust it. Remember -
16. Our rolling example Send mail invoke
18. Extract setup to methods Step 1 Extract drivers Step 3 Simplify the code Step 2
19. Extract setup to methods Step 1 ▪ ▪ ▪ ▪
20. Describe what you are testing Not how you are testing
21. Simplify the code Step 2 ▪ ▪ ▪
22. ▪ ▪ ▪ Extract drivers Step 3
23. It’s actually a cycle. workflow Extract setup to methods Simplify the code Extract drivers
24. Don’t wait, do it Now.
26. try { future.get(); fail("Expected CancellationException"); } Test action WixBiRecordingStudio.record { logEvent() ←-- WHEN } andThenPlay { recording => recording.play must contain(exactly( aBiEventWithEntries("bar" -> "baz", "method" -> "foo"))) }
28. Test Expectations person must beATeenager person must beAmericanTeenager person.age must be_>=(13) person.age must be_<=(18) person.location must_=== "USA"
29. yes rarely Never given when then Define New variables?
30. Failure messages A true story
31. Failure messages A true story Always Make sure that: ★ ★
32. takeaways Test behavior, not code The Test should stand on its own USE ONLY VARIABLES YOU DEFINED yes rarely Never given when then Describe what, not how Start today, DON’T WAIT
33. github.com/noam-almog