Tricky Testing

Not all testing is as simple as setup data -> run code -> test results. Sometimes these steps can be tricky.

In this talk I make the argument that this shouldn't stop you from tackling the problem, though it pays off to think about what you would and wouldn't test and why.

Regrettably, the slides are not very useful without the talk. Will put up a link when the video is online.

Transcript

1. @AndrewRadev
2. Tricky testing
3. waiting-on-rails
4. How does it work? • Start a `rails s`, read its output • Meanwhile, start music, keep pid • When output matches, kill music
5. How is it tested?
6. Conclusions • “Tricky” is often surmountable • Preparation is everything • Understand what you're testing
7. --servername FOO --remote-send --remote-expr
8. Vimrunner
9. Conclusions • Not that hard, actually
10. writable_search
11. Cognitive dissonance
12. When to write tests?
13. Ask questions: • Is it hard? • Is it important? • Is it likely to fail? • Is it fun to test?
14. Be mindful
15. Summary • “Sounds tricky” != “tricky” • Preparation is everything • Be mindful • YOU SHOULD USE VIM
16. Questions?