# What's a healthy code:test ratio?

**URL:** <https://www.ruby-forum.com/t/whats-a-healthy-code-test-ratio/108020>\
**Category:** Rails\
**Created:** [June 28, 2007, 2:10pm UTC](https://www.ruby-forum.com/t/whats-a-healthy-code-test-ratio/108020 "2007-06-28T14:10:20Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![elliterate](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/9de053/32.png) [@elliterate](https://www.ruby-forum.com/u/elliterate)\
**Post date:** [June 28, 2007, 2:10pm UTC](https://www.ruby-forum.com/t/whats-a-healthy-code-test-ratio/108020/1 "2007-06-28T14:10:20Z")

</div>

Hey,

I’m just wondering what people consider to be a healthy code:test ratio  
(as  
shown in rake stats).

Our new code base is currently 1:2, obviously not that great, what  
ratios do  
you lot have?

I’m thinking 1:4 would be a nice ratio, though that’s not a founded  
statement.

I realize this isn’t an accurate metric for analyzing test coverage, but  
it’s interesting at least.

Cheers  
Ian

---

<div class="post-metadata">

**Author:** ![elliterate](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/9de053/32.png) [@elliterate](https://www.ruby-forum.com/u/elliterate)\
**Post date:** [June 28, 2007, 5:26pm UTC](https://www.ruby-forum.com/t/whats-a-healthy-code-test-ratio/108020/2 "2007-06-28T17:26:49Z")

</div>

I think you almost answered your own question. What matters is code  
coverage, and completeness of cases, not bulk ratios.

At the same time I can not imagine a project having every case tested  
completely. That would take more like 1:10 or more. So testing what  
is immportant, and adding tests for every reported defect is at least  
a minimum.

Michael

---

<div class="post-metadata">

**Author:** ![elliterate](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/9de053/32.png) [@elliterate](https://www.ruby-forum.com/u/elliterate)\
**Post date:** [July 2, 2007, 12:48am UTC](https://www.ruby-forum.com/t/whats-a-healthy-code-test-ratio/108020/3 "2007-07-02T00:48:27Z")

</div>

Ian L. wrote:

> I realize this isn’t an accurate metric for analyzing test coverage, but  
> it’s interesting at least.

1 line of code for every 2 lines of test is head-and-shoulders above the  
majority of software projects, including your competition’s.

Let’s assume you are using Test-Driven Development, where you make tests  
fail before writing code to pass them. (Otherwise even achieving 1:1  
would  
be really hard!)

Pay attention to your test quality. If you frequently clone-and-modify  
test  
cases, and if the test cases get rather long and do many things, your  
code  
will indeed resist bugs, and you shouldn’t spend much time debugging.

However, your tests won’t be very DRY. This could account for a high  
test  
line count. Tests should be readable, individual, and self-documenting.  
If  
they do too many things, and if they have too many lines, there are some  
useful techniques you can use to merge them and make them more useful.

You could, for example, perform the “Extract Method Refactor” (look it  
up)  
to merge common assertion code into an application-specific assertion.  
If  
your application requires tied shoelaces, you could write  
‘assert\_laces\_tied(shoe)’, for example. This improves the test’s  
readability.

Next, many tests follow the “Execute Around Pattern”. Look that up too -  
Ruby does it all the time. If your test creates a resource, then calls a  
tested method, then verifies that resource, you could encapsulate the  
“before” and “after” concepts, and put the actual test into a block. For  
example:

def test\_shoe\_laces\_tied  
assert\_laces\_tied do |shoe|  
shoe.go\_jogging(5.minutes)  
end  
end

Now you can write many test cases that create shoes, call different  
methods  
on them, and assert that their laces remain tied.

The next more advanced form of this concept is the “Abstract Test”. That  
means you write two test suites as modules (not classes), and then you  
write  
some Test::Unit::TestCase classes that include these modules, and apply  
different setup() methods to them. Each setup() method creates a  
different  
object, and the inherited test cases check that they all behave the  
same.  
Abstract Test is a good way to enforce objects that obey the Liskov  
Substitution Principle.

–  
Phlip  
[Test Driven Ajax (on Rails) [Book]](http://www.oreilly.com/catalog/9780596510657/)  
“Test Driven Ajax (on Rails)”  
assert\_xpath, assert\_javascript, & assert\_ajax