3 ms·
I'll add a couple of my own "best practices". Use Guard to run tests after each file change - Constantly running and re-running your tests in the background le
by programminggeek 14y ago
I'll add a couple of my own "best practices".
Use Guard to run tests after each file change - Constantly running and re-running your tests in the background lets you know faster when you break something, but also forces you to keep your tests fast.
Use a visual test runner - Using guard is great, but I also like a nice HTML page I can reload that ends up being red/green based on your tests. Going from red to green can be deeply satisfying for reasons I don't fully understand. RSpec has a nice HTML output for ruby.
Use a visual code coverage tool - Having 80% or 90% code coverage is a useless statistic, but having a tool that shows you what part of the code is being tested and what isn't is extremely useful. If nothing else it tells you where you need to add tests or what part of your code is hard/impossible to test. I like SimpleCov for ruby.