Adding Tests to Mature Web App

[skazat]

Hello Fellow Monks,

I've developed a fairly mature web app - it's about six years old now.

Recently, I've been bug triaging/fixing and after about say the 50th bug, I just about lost my mind and thought, "This is 1: out of hand and 2: going to be hard to confirm that these bugs are really fixed"

Which then, I made the executive decision to enforce a test policy using modules such as Test::More.

A few questions:

• This project is already pretty sizable - what's a good way to ease into placing tests for the various components of the project?
• The web app needs some minimal configuration to make it work and most of the app works via the web browser, there really is no command line interface to it, so many of the tests will have to work as if the test app is emulating a browser (I do know about Mechanize and friends). Would anyone be willing to share their strategy on how to work with an environment like this?

Thanks for any feedback you can give - I know much of Perl's strength is its testing suite and I'd like to really get into it, however late I am to the party ;)

[bobf]

Get a copy of Perl Testing: A Developer's Notebook. I've found it to be an outstanding tutorial on how to write tests for both new and existing applications. There is even a chapter on testing web sites (both front and back end), and several examples for Test::MockObject and Test::MockModule.

[Anonymous Monk]

Can I just add that I'm *really* not a fan of the "Developer's Notebook" format?

1) The printing is terrible, dark-blue print with an ugly typeface on a mock graph paper background. And the faux "handwritten" side notes are actually as hard to read as somebody's handwriting. Typography is actually supposed to make something *easier* to read, not harder.

2) The structure of the sections means I'm constantly flipping back and forth, to a degree that I never have to for other O'Reilly books--e.g., they have a section labeled "How do I do that?", then a section labeled "What just happened?" Honestly, I think a section called "What's about to happen?" followed by a how-to makes vastly greater sense. Sort of like writing tests before code, writing what you expect to happen before you show it happening communicates the intent much more clearly.

3) The whole "No lengthy explanations" attitude makes me feel like this was a way for O'Reilly to ship a book 40% of the size of a typical offering (180 pp., including index), and still charge 90% of the price ($29.95 USD).

I know chromatic is both smart and helpful, and I trust that Langworth is, too, but this format really, really bites. There's a lot of information in it, but there's more work to dig it out than should be necessary. I think it has such a high reputation because it's the only book that focuses exclusively on this particular subject.

[adrianh]

While I, personally, find the structure / length completely appropriate I do agree with:

1) The printing is terrible, dark-blue print with an ugly typeface on a mock graph paper background. And the faux "handwritten" side notes are actually as hard to read as somebody's handwriting. Typography is actually supposed to make something *easier* to read, not harder.

The mock graph paper and the right-justified typewriter font make reading the main text a pain. Everybody in the office whose read PDTN has agreed. Pity since the content's nice, and O'Reilly books are normally a model of clarity.

If you're new to Perl testing I'd definitely spend the extra effort to get past the presentation.

[skazat]

Thanks! I'll check the book out;

[duckyd]

Hopefully, most of your core functionality is in modules and abstracted from the presentation. If so, you can do a lot of testing without worring about pretending you're a browser.

As far as adding tests to an existing codebase, In addition to the book mentioned above, Perl Medic has a decent section.

When I've been in a similar situation, I've tried to add the simplest test(s) possible without changing the existing code at all, and then slowly re-factored the code to make it more test friendly (if needed) while keeping the original tests in place to verify nothing's been broken. Usually when I'm up against code without tests, I didn't write it, so you may be a step ahead in that regard.

[skx]

I'd second this comment.

I took over a large and mostly monolithic application. At the time there were no test cases and so I went through and did two things at once:

• Wrote test cases against an imaginary modular-API.
• Broke the code into many small modules.

Over time 99% of the code has been turned into objects and modules and now I have a good place to add more tests.

Testing a large monolithic application is quite hard.

Although if you can install an instance upon a test environment (perhaps along with a test database with contents, etc) you may be able to use the WWW::Mechanize family of modules to fire requests against it and parse the results back out.

[adrianh]

I second the recommendations of Perl Medic & the Testing Notebook.

For adding function/acceptance tests onto an existing web app I'd also look at Selenium and wtr (ruby - but good :-)

You may also find the non-perl book Working Effectively with Legacy Code a useful read.

[lima1]

Write tests for your bugs before you fix the bugs. Check your test coverage with Devel::Cover before you refactor some code. If not all lines that are affected by your planned refactoring are covered, write tests. If you add new features, write tests before implementing the features. Don't waste time: don't write tests for mature code that you don't plan to change in the near future. It is no problem that you are late. The biggest problem is that your core API is probably not as clean as it should be for nice tests, simply because you did not need a clean API. Your test strategy depends on your existing code base. Maybe it is ok to refactor (modularize) your configuration code because it would not be too much work. But generally it is a bad idea to refactor mature code just to test it easier.

[ides]

You might also want to look at the Apache::Test framework for testing.

[tphyahoo]

you could have a look at iopus internet macros.

it's primitive, not perl, not free, but easy to get started with: it's basically an automation tool for Internet Explorer, like word macros are for Word....

it does interface ok with the windows shell scripting tool.

if you have some interns sitting around the office with lots of time but little experience, you could give them this program to start recording click scripts, and at least this would give you a basis for turning things into more structured type tests with perl later.