The rails project I'm talking about is over three years old and has seen commits from 27 developers in that period. These developers were both co-workers, freelancers, off-shore developers and designers of different levels of expertise.
**The test suite takes approximately eighty minutes to run.** These are all RSpec tests, including features. Luckily we can split the entire suite up into smaller parts using Travis, but still the entire thing takes about forty minutes.
The main cause for these slow specs is a lack of understanding about how to write _good tests_. For example, testing if search and pagination works, someone thought it fine to create fifty ActiveRecord objects in a before block.
**This project has no cucumbers to discuss and review features with Product Owners.** These cucumbers would have been awesome to discuss features both with product owners and team members. But at the start of the project cucumber was deemed _too much hassle_ and Rspec feature specs were used instead.
The main issue now is that the line between features specs and unit specs is a thin one and people often mistake one for the other. This is probably one of the reasons so many specs create many models and make the entire suite slow.
**There are parts of the code that are not well tested - or not at all.** This is a dangerous one. Because, from the start, nobody monitored test coverage or did proper code reviews, there are patches of code that are not well tested, and there are some that are not tested at all.
**Lots of smells and lots of noise.** All the points above indicate there is a certain amount of technical debt in this project. Another pointer are _code smells_. To name a few I've seen over the past few months:
The product we ship works. Although the specs take a long time to run, and there are some code smells in there, the suite is actually green and we have confidence the product works as expected.
Responding to change is still possible, but it's a bit more painful than it should have been. There are some untested patches of code that we would really would like to see tested. And of course, code should be readable and easy to understand. We don't always have these things and it's holding back progress sometimes
It's not about fixing all the things. It's about improving the things you touch just a tiny bit. Over the course of a few weeks or months these small improvements start to add up and really make a difference.
Your new specs suite is fast and elegant. Use it to refactor the existing codebase to make change easier.
Congratulations, you have just made your life much easier. Note that you have not written a single line of code yet for you new feature or change. But the cleaning up you just did will greatly benefit you and the time it takes to write this feature.
You should not wait until you hit the technical debt limit of your project. Minimizing technical debt is just as important as writing tests. It should be a team priority from _Day 1_.
Minimizing technical debt is not all too different from doing proper test driven development. It requires rigorous discipline and skills. And just like with tests, you will not handle that technical debt after this crunch period.