from Hacker News

We don't write tests. There just isn't time for luxuries.

by byosko on 10/3/07, 3:56 PM with 43 comments

  • by breck on 10/3/07, 6:07 PM

    I'm a chronic manual tester. But I want to start getting into automated tests.

    What are the most important things to test? What are some good intros to pick up the basics on writing automated tests?

  • by geebee on 10/4/07, 8:46 PM

    "Everybody Tests" is a good point. Some devs throw away their tests, and other devs keep the tests around and run them periodically, but devs who write code iteratively (which seems like pretty much all of them) write something that could be easily turned into a unit test.

    If you don't like TDD (and I have to admit I'm not a fan), you can still produce tests while you write code (you probably already are). Whenever you write a bit of code, you probably do something to check whether it is producing the expected outcome - even if it is as simple as writing a little script to generate some output that you visually inspect as it flashes by on the screen. If it looks good, you keep developing. If it fails, you figure out why.

    Just store your these mini-testing scripts in a unit test, and verify the expectation/output in a short statement. If you use a framework, you'll have some methods for this available to you - if you don't, no biggie, just write something that honks loud and gives you a message diagnosing the failure.

    It's not going to satisfy the TDD crowd, and honestly your coverage won't be as good as if you had done TDD, but there you go - you just got yourself some unit tests, and you didn't have to disrupt the mental flow that you prefer to TDD.

  • by euccastro on 10/4/07, 9:42 PM

    I wrote some opinions on this in other thread:

    http://news.ycombinator.com/item?id=46526

    Unless your software will kill people if it fails or something, my advice is: observe what proportion of your development time you spend debugging. If it's one half or more, unit testing would probably benefit you. If it's significantly less than 50%, then you're probably better off riding bareback, because writing and updating those tests will take at least half of your time.

    The problem I see with the "you'll test anyway, you may just as well automate it" argument is that unit tests are no substitute for testing with real users.

  • by bsaunder on 10/3/07, 9:21 PM

    "the break even point for an automated tester is when they've run their tests twenty times"...

    I find that (at least in early development), when I'm in the zone I refactor several times a day (differnent parts of the system of course). If my break even point is twenty times, I'd never get there. Every refactoring would virtually obliterate all of the previously automated tests.

  • by niels on 10/3/07, 8:01 PM

    I've recently begun using automated tests of basically all my code. Both frontend and backend, when I'm doing web stuff. I usually write the code to a minimum first, and then implement tests. It's a huge relief to use these tests when I refactor and refine code. I definitely think automated testing is the way to go in most cases.

  • by imsteve on 10/3/07, 5:30 PM

    Sometimes it just does slow you down overall.

    Remind me again, how many web startups have failed because of a bug? How many? Hm.

  • by edw519 on 10/5/07, 11:57 AM

    I have always believed that there is an inverse correlation between the amount of precise attention devoted in design/development and the amount of time spent in any debugger. Nothing here changes that thinking.

  • by brintoul on 10/3/07, 5:35 PM

    I dislike writing more code for my tests than the "actual" code. I do not eat the "test driven development" drivel hook-line-and-sinker. Sorry, call me an unenlightened developer.