This page is about how I test. It is certainly not total correct, but I do welcome comments on ways to improve.
Rules for testing
I used to be one that believed that everything had to be tested. I still believe that, but now I know that different things need to be tested differently. I have come up with some guidelines that I generally use.
- The goal of testing is to know when something is “done”.
- Don’t test the functionality of library code (gems), but do test the integration of them.
- If testing something is difficult then you designed the “thing” wrong.
- Check for standard patters, or
- Drop to a lower level test.
- Only stub things you own.
- For things you don’t own, memoize (VCR is good for http request memoization)
- Don’t write code until there is a failing test
- Coding “confidently” can ease the test burden
- For a customer / Product manager requested features use Cucumber
- Define the idea of the test ahead of time, and get buy-in before testing.
- Only write features of interest for the customer.
- For feature that are a requirement, but not of interest for to your customers, use Rspec feature tests
- Those high level phrases become your steps.
- If cucumber is confused then so will your customer.
- For uninterested customers start with feature testing in Rspec
- The same tools are used (capybara), but it is faster in both terms of time and in terms of coding
- Start with integration/acceptance testing
- Each failed step is an opportunity to drill into a unit test
- Move down when tests failure no long talk about the code at hand
- When a test passes move sideways to another test in the same area.
- When all tests pass in an area move back up
- “Done” is when all acceptance tests pass
The Testing Stack
Everything here is based on a Ruby on Rails app. Currently 3.x Rails. 4.x will likely change things
- Capybara Webkit
- Factory Girl
- Database cleaner
Everyone has their opinions on testing. I know MiniTest and use it when a project that I submit to uses it, but my projects use Rspec.
Ok, so let me just get it out there: Cucumber is evil. Don’t get me wrong I like cucumber, but I have gotten myself into so much trouble using cucumber. Granted the issue was that was using cucumber to write specs, but nothing in the cucumber world made it seems like that was a bad idea.
The debugging stack
As you are testing inevitably you will run into an error that tests can’t explain. Here are the tools that I use.
- Pry Rails
- Better Errors
- Letter Opener
- Exception Notification
Why no debugger???
My experience with debuggers has always been that they are for programmers that don’t first test their code! I have been coding for over a decade and find that debug print statements are more reliable and consistent, unless you working in assembly. Even embedded systems with no file system have syslog clients.
Basically just replaces
rails console with Pry. Pry makes it easier and cleaner to drive into objects, but I always have to remember to only include it
development and not
Replaces the standard error screen that is displayed when an exception is thrown with a better look screen.
Opens email messages in a browser window. This makes it easier to see what the end email is going to look like and it doesn’t involve an email server.
This is a MUST have for production! But it sends a full stack trace email if your app fails in production. Now you will know about site failures and can debug them before you get a support ticket.