Tricky Testing

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.

Fc59401781a26b10f5d4fc5b758fb3b7?s=128

Andrew Radev

February 07, 2014
Tweet

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?