Rails App Without Tests = Guaranteed Fail 19

Posted by Kurt Schrader Thu, 07 Feb 2008 09:15:00 GMT

My friend Jay wrote a few days ago:

I bet of you looked at the majority of Rails applications you would find empty test folders (or only the generated tests, which are never run). I'm quite sure that's true because I expect the conferences to attract the best of the Ruby developers, and several of the people I talk to at those conferences "simply don't have time" to write tests.

These people are idiots. Either that, or they don't have any sort of complexity in their apps and they're writing them in a far too simplistic and elementary way.

Quite often, doing a little meta-programming magic in Ruby can make you massively more productive and, in my experience, the only way to find the side effects of doing a lot of meta-programming is to have a comprehensive test suite. As this magic-level in your app increases, the number of side-effects of that magic will also inevitably increase.

Eventually, you will get burned by something if you're not ready for it.

Tests are your flame-proof suit in this case. They're not going to protect you against everything, but most of the time they do a damn good job of keeping you alive.

DHH wrote the other day:

We try to do a fairly good job at keeping our test suites current and exhaustive as well. Basecamp has a 1:1.2 ratio of test code (thanks to the persistence of Jamis!), Highrise has a ratio of 1:0.8 (bad me!).

At CDD, our current code to test ratio is 1:4.2.

Overtested? Undoubtedly.

However, we don't want to ever have to go in and fix the damage after someone tries to import 1,000,000 molecules to our system and something goes wrong. The repair work can take days in some cases, so we err on the side of caution.

I'll wrap this up with the following three easy points:

  1. If you're writing a Rails app, write tests for it.
  2. If someone who works for you "simply doesn't have the time" to write tests, fire them.
  3. If a consultant tries to give a Rails app without a test suite, fire them (and don't pay them, if at all possible, what they've given you is pretty much worthless, and is going to be a nightmare to maintain).
Comments

Leave a comment

  1. Avatar
    Eliana about 2 hours later:

    Great advise. I should now start requiring tests for my rail apps. I do get the bugs once in a while before but never really asked for solutions.

  2. Avatar
    Georgina about 2 hours later:

    I’m agreeing that on every application without doing test, its guaranteed fail. Even on an invention, the inventor make test first before launching to the people his kind of invention. Just to make sure if it’s working and useable by its users.

  3. Avatar
    kolskal@hotmail.de about 3 hours later:

    Tests are for wimps. Deploy like a man. Real programmers don't need tests.

    I have been programming in rails for years, and have never written a test. Nor do I need to, there are no bugs.

  4. Avatar
    Ben about 4 hours later:

    Having a comprehensive test suite is important, but don't you think that focusing on the test-code ratio (or numbers from rcov, to take the logical next step) is a mistake? I wrote up my take here.

  5. Avatar
    Zach Inglis about 6 hours later:

    While I agree test suites are important, it depends what iteration of the application you are on. If you are doing prototypes, then tests are not needed. if you are talking the final draft, I agree tests are needed. But too many times do I see people testing for if Rails works correctly rather than their app. Also, When you have a very simple CRUD app, I don't think testing is the be all and end all. When dealing with Math or such I do agree though.

    Too many times I have seen people fall behind on an application because they are writing tests. Anyway, you should be competent enough that you KNOW your code and that nothing goes wrong, so tests should be a secondary failproof.

    And calling these people idiots? That's a bit harsh. Misguided or having their own opinion maybe?

  6. Avatar
    gregf about 14 hours later:

    Rails App Without Tests = Guaranteed Fail <<< Yes because man never wrote any working software before tests came about.

  7. Avatar
    Mr eel about 15 hours later:

    "If someone who works for you "simply doesn't have the time" to write tests, fire them."

    Never mind if: a) They're competent programmers who do good work b) Don't actually have time

    …blah, blah just fire them. Right. Perfect solution. It seems like decisive advice, but it's an extreme solution to something that can be resolved in other ways.

    "Rails App Without Tests = Guaranteed Fail"

    No sorry. That's a load of horse-pucky. It can increase the potential of failures going unchecked, but it's not a guarantee.

  8. Avatar
    Kurt Schrader about 15 hours later:

    Zach: I've seen many more times when people fall behind because of a lack of tests, once the application gets big enough. I guess that I should have clarified that I wasn't talking about toy apps.

    Mr eel: They do have time. It will save you time later. You're fired!

  9. Avatar
    cag about 17 hours later:

    Now if we just had enough money to hire a tester to test the tests.

  10. Avatar
    tom 1 day later:

    A bit harsh. Sometimes you write applications in a domain where bugs dont really matter all that much. In those cases, if you stick to the standard rails stuff and dont go to crazy on the meta programming magic, tests arent a huge deal.

    Hell, 90% of my reported bugs tend to be on the CSS/Javascript side anyways. Rails tests arent going to help much there.

  11. Avatar
    Ermar 1 day later:

    Test is just doing for security measure. To avoid mistakes and less time effort if they failed.

  12. Avatar
    Mark Wilden 1 day later:

    I hate testing code. I can't think of many things more boring than writing a test for code that already seems to work.

    That's why I write the tests first, before the code. Then, writing tests is part of creating code, instead of an unpleasant chore afterwards.

    Of course, everyone knows about TDD these days (I've been using it exclusively for seven years). But I haven't heard it mentioned that one of TDD's biggest benefits is not having to write tests for existing code (or at least not so much). TDD makes testing a part of programming, instead of a part of QA.

    ///ark

    (@Zach: Thanks for the laugh)

  13. Avatar
    ken 1 day later:

    "I hate testing code. I can't think of many things more boring than writing a test for code that already seems to work."

    I love it. Especially when it's my coworkers' code. How can I be positively evil today? Muahaha.

  14. Avatar
    john 1 day later:

    Well you're a real stooge. Have you ever considered that you've been sold a load of shit with the whole "test infected" thing? That you're perpetuating money transfer from agile conference proceeds and book sales to the likes of Dave Thomas and Martin Fowler?

    Before you go running your can, run your own business and evaluate how much test coverage means to you then, when you have the luxury of choosing between building value and crying "the sky is falling because we don't have enough tests!"

    Oh, I forgot, you're busy "saving the world from developing diseases." ...Probably slurping up charitable donations or tax dollars making sure you have your 1:4.2 and wasting everyone's money.

    Get a clue.

  15. Avatar
    test(kurt) 1 day later:

    Testing ratio 1:4.2?

    Did you even bother testing the UI? if yes, what's the ratio? 1:4 as well?

    This sounds more and more like Microsoft with their SDET.

    I'll fire you for wasting my money.

    Son, you're just a beginner in this field.

  16. Avatar
    remi 2 days later:

    Wow, there are a few pretty harsh comments here ...

    I don't quite understand how folks can be against testing. I understand people who don't test because either they haven't gotten into it yet or because it's just not how they do things ... but to be against it?

    I don't know about other people out there, but test-driving my code has made me more productive. I seem to get things done faster for a number of reasons:

    • if I don't know or forget some part of the app's API, I can always check specs for examples
    • the API tends to stay clean, even as the app grows, as tests make refactoring so trivial (and not scary)
    • I don't have to worry about introducing new bugs, because the tests explode and let me know
    • When bugs do show up, the tests generally make the bugs faster to fix (and, if it's a bug the tests didn't catch, adding a test to catch the bug helps keep it from coming back)
    • I never waste time 'dilly dallying' or adding functionality that's not needed, because all I do is write & implement the specs

    TDD has made me a much happier and more productive programmer. I no longer worry about apps exploding and, interesting, I never waste time TESTING! Because my tests are constantly running, I hardly spend any time at all having to manually test.

    "Anyway, you should be competent enough that you KNOW your code and that nothing goes wrong, so tests should be a secondary failproof."

    @zach: Often my tests help me because I don't know my code very well. We all know what it's like to come back to your code after a month or more - even when it's coded well. I have to jump around between projects fairly often and I find that my tests really help me do that easily. Not only can I check my specs for a refresher course on API usage, but I can check my current list of pending/incomplete specs and start right where I left off :)

  17. Avatar
    notests4me 13 days later:

    Tests are over-rated. Sure they have there usefulness but I look at it this way - if it were a tangible product coming off an assembly line - would you test the product or would you test what your tests think the product ought to be?

    So I prefer things like selenium where you get more rubber on the real road.

    Oh and I like my code as simple as possible - I'm not a brain surgeon :-O

  18. Avatar
    E. James O'Kelly 21 days later:

    There is a middle ground here people. 1:1.42 sounds quite overtested, or more probably you are testing things like rails functionality (associations, validations) that you are wasting your time testing. That or you are testing views.

    I am not a huge tester after seeing several projects fall behind due to TDD junkies forgetting that we have a job, and that is to ship an application, not write test suites.

    I have been building web apps for over 10 years now and never had testing until rails. When you are used to constantly viewing the pages and trying to get them to break while you are coding you catch everything anyway.

    I'm not saying testing is bad, over-testing or not testing is bad.

  19. Avatar
    E. James O'Kelly 21 days later:

    And anyone who condones not paying consultants is a prick and a thief in my book. You are talking about robbing your own ecosystem here, not typically smart to shit where you eat.

Comments