What is a good practice when writing tests for a project that hasn’t followed TDD ? Should one focus on defining scenarios and start with integration testing, or review each controller/model/helper and have Unit tests, before moving to Integration testing (for example with capybara)?
Models and Helpers normally have a quite granular structure allowing for easy Unit testing, but this is not the case with Controllers in my experience.
First, I’d go get this book: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Lots of good advice for dealing with this exact scenario.
But until it arrives, I have some basic advice. Try to establish a small area of the app that is tested. When you add new functionality, make sure to TDD it.
When you change existing functionality, write a few tests for the area you’re about to change to help ensure that the modified component will continue to function.
You also might want to write a small handful of integration tests for the app’s most important duties.
Here’s another approach that might work for some situations. In my case, I have an old Rails app I want to upgrade and it’s also one that doesn’t have any tests.
I created a fresh Rails (3.2.13) app, and wrote a feature for being able to login to the app. At each failure point, I look to the existing source code and copy it into the new application, one piece at a time. That way, I know I’m writing tests that actually fail if there’s a problem. Once I get a feature spec passing, then I refactor and move on to write my next spec.