Archive for the ‘TDD’ tag
Good tests are fungible
Over time, good programmers build up a library of working code which gets ported from project to project.
Having a library of test code makes this even easier. Instead of messing around with the code, port the test code first. It’s much more fungible.
Three reasons for writing and maintaining framework tests
The received opinion in the software engineering test driven development community is “never test your framework.” This is good advice. And like most good advice, there are exceptional reasons why framework testing might be appropriate:
1. If the framework is undergoing rapid development and is not well-covered in tests, ensuring the framework acts as assumed before running your own tests might save a lot of debugging time later. This is especially true when the API is changing fast.
2. When you don’t understand exactly how the framework behaves, a few tests will help clarify what’s going on. For example, a recently popular CSS framework “decided to be helpful and sneakilly [sic] stuffed jquery into the minified <framework>.js file. Everything worked fine except the ajax:whatever call backs when using remote => true.”
3. I forgot reason three, which is annoying because I started this blog post with three reasons in mind.
Where to test a framework
Some guidelines:
- If it’s mission critical, have a small, separate suite of tests which run independently.
- If it’s for clarity, or for watching something liable to change in the future (such as the ongoing webrat versus capybara matchers issues), drop a framework test right in with a particular spec.
There is a fine line here, easy to cross, but it’s also a line as much in the eye of any particular beholder. That is, when and where to add a few framework tests depends a lot on the developer’s opinion.
Test Driven Development – Yea or nay?
Here’s an interesting observation I’ve made as a result of reading (over the last 10 years) the pros and cons of test driven development (TDD). The discussion seems to eventually get this point:
- “TTD is a crock. I just don’t see the need to fully test everything. It’s a waste of my time.”
- “TDD is awesome. We found TDD really helped speed up our development and ship better product.”
Feel encouraged to draw your own conclusions.