Building a test environment

I have written a web application that I would like to write tests for.

Originally, I wrote the application and the tests in parallel, but that fell apart under time pressures. The problem was, I had to prime the database up a certain way for the tests to work.

I have since reasoned that the proper approach is to stat with a clean system and build the test environment, then test against that. Finally, part of the test would be the removal of the files, projects and users creating during the test -- leaving the system as pristine as it started.

There are two features that will be tough to test in a 10-15 minute test:

Users are created with temporary passwords, and they have to log on and reset the password
Files are aged, and go from being new to being stale and then being automatically deleted over a period of four weeks.

The solution to the first problem is probably that I run a first test to create the users, then manually reset the passwords to known values, and finally run the rest of the tests. As far as checking that files are aged properly .. any suggestions?

As always, thanks for your feedback.

Update, re: consideration: I posted this to Meditations rather than SoPW because it was more of a metaphysical question than a 'How do I code this in Perl' -- but it doesn't matter to me where what section it lives in; I'm just happy to get the feedback from the monkish population. --Alex

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Comment on Building a test environment

Replies are listed 'Best First'.
Re: Building a test environment by derby (Abbot) on Jun 05, 2007 at 14:00 UTC
It seems to me you have two courses of action wrt to the aging: muck with the clock/timestamps make the aging configurable For the first, you could use the touch command with a certain date (in *nixes) to prematurely age the files: `$ touch foo $ ls -l foo -rw-rw-r-- 1 user group 0 Jun 5 09:58 foo $ touch -t 200705050958 foo $ ls -l foo -rw-rw-r-- 1 user group 0 May 5 09:58 foo` [download] For the second, is there really any difference in testing the lifespan across a month as opposed to 15 minutes? -derby	[reply] [d/l]
Re^2: Building a test environment by Fletch (Bishop) on Jun 05, 2007 at 14:03 UTC
Or just use the builtin utime (which coincidentally was mentioned just the other day (coincidentally also by me . . . :)).	[reply]
Re^2: Building a test environment by talexb (Chancellor) on Jun 05, 2007 at 14:56 UTC
Again, sorry, I didn't put all of the details into my original post because the PM server was so slow this morning. The timestamp on the file isn't considered -- instead I have a script that does an hourly check, comparing when the file's database record was created with the current time, and doing the appropriate aging by advancing a file to attention (after 2 days), stale (after 14 days) or deleted (after 28 days). I may have to write a script that 'artificially' ages files by a certain amount to get the test to work -- perhaps by back-dating some of the database fields, then running the hourly check script. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re^3: Building a test environment by perrin (Chancellor) on Jun 05, 2007 at 16:17 UTC
Changing the dates in the database sounds like the best way to test it to me.	[reply]
Re: Building a test environment by perrin (Chancellor) on Jun 05, 2007 at 13:50 UTC
You could make your newly created users log in. It's just another Mech request, right? As for the file, you can set their age with the touch command or override the way your code finds out what day it is.	[reply]
Re^2: Building a test environment by talexb (Chancellor) on Jun 05, 2007 at 14:51 UTC
Yes, sorry, the PM server was so slow this morning I didn't do my usual compose, compose, compose, compose, compose, compose, post cycle. Here's more detail. The user names are E-Mail addresses, and a new user is E-Mailed their temporary, one-time password. They have to use that to log in, and the only thing they can do is set their password to a new value. My SysAdmin has set up a couple of E-Mail addresses that just re-direct to me, so right now I think my plan is to run the first part of the test, then perhaps have the test pause, while I use cut and paste to change the test users' passwords to known values, then continue the test. It's a little clumsy, which is why I was asking for guidance. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re^3: Building a test environment by perrin (Chancellor) on Jun 05, 2007 at 16:04 UTC
The way we handle e-mail on my current project is to run SMTP-Server and have the mail we want to test sent to localhost. It shows up as a file which you can then open and extract what you need. It's a little cumbersome, but doesn't rely on any outside network configuration.	[reply]
Re: Building a test environment by jagh (Monk) on Jun 05, 2007 at 18:30 UTC
This sounds like a good candidate for some sort of unit testing. If I grok your post (and I'm not sure I do :), it sounds like the problems you're running in to come from trying to test the application as a whole. You might try breaking it down into units, and testing each of them individually. As a trivial example, take the login function. Your unit test could set up a fake DB, run the function that checks credentials, and check the result. The user creation test could work in a similar way, running the code with some supplied input, and then checking the resulting DB entry. Right now, it sounds like you're trying to create the user, log in, and use the application all in one test (correct me if I'm wrong). Most unit testing code will allow you to do things like this, starting with a clean environment (FS, DB..), inserting some test data (files, db records), running the code (a few runs of some function with different input), and cleaning up. I've never done unit testing with /perl/, so I don't know what's out there, but a quick google suggests that there are more than a few frameworks for perl. Hope that helps.	[reply]
Re^2: Building a test environment by talexb (Chancellor) on Jun 05, 2007 at 19:20 UTC
Thanks -- I'm not sure unit testing is possible, but the idea of using a mock database is starting to look like a really good idea. This is a CGI::Application doodad, something I should have mentioned earlier .. and Andy Lester suggested Test::WWW::Mechanize a while back .. I'll have to look at that as well. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]