Code Quality: Metrics That Matter
As programmers, we spend a lot of time and bits debating and preaching about the merits of good code and the evils of bad code and the differences between the two. And as Rubyists, we sometimes get a littleÖ What? Self-righteous? Precious about our code? Strong tendency to bikeshed?
OK, weíve all probably been guilty of that at times. Most Ruby and Rails hackers Iíve worked with and known over the years show a lot of care and craft when it comes to their code, but we do it all in the service of building something that lasts. This is why we go on about skinny controllers and presenters versus helpers. Itís why we write tests. And itís a big part of the motivtion that has led to the creation of so many tools for evaluating source code quality. This article is going to talk about a few of them that Iíve found useful at various times.
But before we launch into that, thereís an important question that needs answering:
What Are You Gonna Do About It?
No, seriously, thatís a real question.
If all youíre interested in is how to install the gems and run the reports, a bulleted list of links to the READMEs will do just fine. Before you invest any more time, I want you to think about what youíre expecting to learn from them and decide right now what youíll do when you have that information. This is the piece thatís missing in a lot of the articles and tutorials Iíve seen about code quality tools, and thatís what Iím hoping youíll be thinking about as you read on.
Coverage matters, but often not in the way people think. A lot of people think that well-covered means well-tested and that well-tested means correct. But just spend a moment thinking about those two statements and youíll see that there are two big logical leaps in that thinking.
A lot of teams chase after 100% coverage for its own sake or as a seal of approval that they can show to a customer or manager, but there are legitimate reasons to work for high levels of test coverage on your projects. First and foremost is the fact that gaps in coverage are indicative of gaps in your development process. Looking for sections of code where coverage is missing can get you asking the right sorts of questions about why it happened.
Was there something about that code that made it too hard to test?
Is that section a candidate for refactoring?
Does the person who wrote the code need some coaching or guidance to help them improve their testing technique?
Another reason that coverage is important, especially when it comes to Ruby applications, is because it gives certainty that code is executed under test. Why is that important? Because eventually, youíre going to need to update some part of the infrastructure that your application rests on - whether thatís the Ruby interpreter (13 releases in the past year), Rails (12 releases), or some other gem you rely on. When that day comes, having a test suite that covers most or all of your application will mean you donít have to worry that something is going to blow up in production because of a deprecated method or API.
... to read more articles, visit http://sqa.fyicenter.com/art/