Forum: Ruby on Rails What's a healthy code:test ratio?

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
3ddf2897026370c1b869159ba19124ec?d=identicon&s=25 Ian Leitch (Guest)
on 2007-06-28 14:10
(Received via mailing list)

I'm just wondering what people consider to be a healthy code:test ratio
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

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

588ab1c0a5610a7e160a3b101abb91e6?d=identicon&s=25 Michael Latta (Guest)
on 2007-06-28 17:26
(Received via mailing list)
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.

Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2007-07-02 00:48
(Received via mailing list)
Ian Leitch 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
be really hard!)

Pay attention to your test quality. If you frequently clone-and-modify
cases, and if the test cases get rather long and do many things, your
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
line count. Tests should be readable, individual, and self-documenting.
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
to merge common assertion code into an application-specific assertion.
your application requires tied shoelaces, you could write
'assert_laces_tied(shoe)', for example. This improves the test's

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

   def test_shoe_laces_tied
      assert_laces_tied do |shoe|

Now you can write many test cases that create shoes, call different
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
some Test::Unit::TestCase classes that include these modules, and apply
different setup() methods to them. Each setup() method creates a
object, and the inherited test cases check that they all behave the
Abstract Test is a good way to enforce objects that obey the Liskov
Substitution Principle.

  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax
This topic is locked and can not be replied to.