Ruby/Rails test practices

While I still considered myself somewhat of a noob in the ruby/rails space, I'm interested in forming an opinion on how I'd like to test rails apps - which technologies and levels of coverage to use and when. My current policy is to go with the flow of whatever project I'm on, but that has yielded inconsistent results in both technology and level of coverage. The only consistency has been in the test first development style.

Rspec for controllers, models, and helpers, cucumber for functionals (to ease the test first development) and backfill with Test:开发者_开发问答:Unit for tricky bits of code? All functionals with cucumber? Abandon Test::Unit? Test::Unit for models and helpers, and cucumber for everything else?

Please share your opinions.

---

When it comes to testing applications, one of the most important things, more important than your testing framework or methodology, is to write testable code.

If you're using a test-driven approach to developing, you'll naturally tend towards writing testable code, but you still need to focus on giving yourself the proper facilities. The goal is to have an application that's transparent.

Some of the things to focus on are:

• Keeping your methods focused on a particular function and providing clear hand-off points between one method and another.
• Providing sufficient introspection into the internals of a unit-level object without needlessly exposing too much information.
• Creating HTML documents that are structured in a way that maps more closely to the controller and model space by applying consistent terminology and naming conventions.

I've always considered testing to be similar to what a magician does. A magician makes it clear what they are doing, and what the results are, but the process itself is not necessarily explained. This is like software where you want to know the results, but should not be concerned with the implementation details.

A typical magic routine shows you all the relevant details, like the performer is wearing a hat, and that the hat is empty, that there's nothing up their sleeves, that the hat is sturdy and weighs very little, and then they will go about pulling a rabbit out of their hat somehow.

Personally I tend to lean more heavily on writing solid unit tests, and by keeping controllers thin, less emphasis on functional tests. Functional tests can be very tricky to get right because of the impossibly large number of states the system might be in when rendering a page. As you can only test a small fraction of these, you will need to prioritize your validations.

Integration tests work well for mature applications that are well defined and where the cost of a defect is very high but otherwise they may take significantly more time to create than a disciplined, rigorous application of quality control. A bad integration test can give you a false sense of security and may actually reduce application quality.

If you have a dedicated QA department that can focus on building and maintaining a full suite of regression tests, then integration testing is a great thing to have. For the average developer, though, it ends up creating an enormous duplication of effort and can be a serious drag on productivity. Like many things it is about trade-offs.