in reply to how to begin with testing?

I personally wouldn't write tests for already written and working application, it's a lot of work and if application already do its job then why bother? But if I eventually find some bug, I'd write a test that demonstrates this bug before I would fix it. My opinion is that tests most useful if you write them before code, writing the complete test suite after code is a waste of time.

Replies are listed 'Best First'.
Re^2: how to begin with testing?
by JadeNB (Chaplain) on Mar 22, 2009 at 23:19 UTC
    While your advice for when to write tests seems spot on—before writing (much) code, and when bugs are found—your advice for when not to write them seems suspect. Even when a complete, working application is in place, it's appropriate to buttress it with tests—they will help with maintenance, so that changes can be seen not to break existing behaviour, and, well, testing, perhaps revealing that an application that seemed to be both complete and working is neither. Since writing tests, especially in Perl, can be very cheap, and need not be done all at once, it seems harmless at worst.

      Ok, maybe I made this too categorical. Of course tests would be useful on any stage of program life cycle. I just think that price-usefulness ratio would be too hight to develop complete test suite after program is ready. You saying that writing tests very cheap, hmm, for me its usually more than half of the time I work on a program, so I'd say it rather expensive.

      What about maintenance -- yes, I would write tests when I have to maintain program without tests, but again that would be individual tests, not a complete test suite, nobody would pay me for that. The only case I would write full tests is if I'm going to seriously refactor some old stuff; but I would do it just before refactoring and not just after writing a program, because I don't know what requirements would be, if at all.

Re^2: how to begin with testing?
by duff (Parson) on Mar 23, 2009 at 02:10 UTC

    Why do you think that writing tests after you have working code is a waste of time?

    As already mentioned, having tests for the code at leasts helps spot regressions when you have to modify the code later. But, more over, even if you have a completely functional application, writing tests can help you uncover areas where there are possible misconceptions before they are found in the live app. Even if the app is working, that doesn't mean it's working as it is supposed to, but you may not realize that without taking the time to write tests against the application.

    My humble opinion,

Re^2: how to begin with testing?
by DrHyde (Prior) on Mar 23, 2009 at 13:53 UTC

    Agreed, with one exception - that being if you want to re-factor the code or make major architectural changes. Then you need tests that exercise the application thoroughly so that you can be sure that your changes don't break anything.

    As for how to write an application in such a way as to be easily tested - instead of a huge monolith, break it into chunks so that each little bit of functionality can be easily tested. For example, if your application has a config file, then instead of scattering configgish stuff throughout the app, abstract it out into a module that provides functions for reading and parsing the file, and for getting at the information, which can be tested entirely seperate from the main body of the app.