Rails Magazine - Issue 3

34
How to Implement Automated Testing by Eric Anderson
34
Declarative Code
Another abuse of testing I often see, related to the 3rd
party code issue, is testing declarative code. The previous
code example was very declarative but let me give you a more
subtle example.
class Notifier < ActiveMailer::Base
def refer_a_friend(to, sender, url)
recipients to
from sender
subject ‘A referal from a friend’
body :url => url
end
end
Does the above code need automated testing? Probably
not. However, if we added some logic to our method or email
template, then the code becomes less declarative and more
procedural. As the code does this it starts to become a good
idea to add some automated tests to ensure your procedural
code is behaving correctly.
Markup Testing
Often, developers will over-test an application’s output.
This can make it very high maintenance to update without
It's going to blow
providing much benefit in return.
A perfect example of this is the markup in your templates.
Testing for certain key bits of markup in your generated
templates can be useful to automatically determine if your
templates are being generated correctly. But it’s a mistake to
start testing too much markup, as it is very likely to change as
the design of the application evolves.
Your automated testing will never be able to see if the page
“looks” right. So, by over-testing markup, all you’re doing is
increasing maintenance costs when someone does want to
make markup changes.
Testing For Error Messages
Another area where developers over-test is error messages.
It’s a mistake to test for specific error messages. Error
messages are very likely to get reworded so testing for the
exact text will make your tests fragile.
Instead, try to find a way to test that an error occurred and
maybe what type of error without doing character by character
comparison of the error messages. Perhaps you can check
a error code or verify the exception thrown was a certain type
of exception.
For example, in a functional test of a controller you
may want to make sure the flash[:warning] was set and not
flash[:notice] when testing to ensure an error is processed
correctly. The actual text of the flash message is less important.
What is more important is that the correct type of flash
message was set.
Final Words
It’s important not to be lured into thinking that because
your tests pass, your application is bug-free. Absence of failure
is not proof of perfection.
Automated testing should be considered a first step. Make
sure to use your application in a real browser and use it often.
Setup your application to report errors to you. Tools like the
exception_notifier plugin are extremely valuable because your
automated testing is only going to test for the things you can
guess might go wrong. But that is really just a small fraction
of what can go wrong.
In conclusion, automated testing is an excellent tool to
speed up development and integration, avoid regression and
gain confidence in your application’s correctness. But don’t
fall in to the trap of blindly implementing thousands of tests
just because someone says you are a bad developer if you
don’t. Often 100% coverage is overkill and it can sometimes
even be a detriment to your application. Instead, always consider
your end goals when developing a test suite.
Discuss: http://railsmagazine.com/3/9