Stopgap measures when you don't have a QA department

[Ovid]

Currently, we do not have a Quality Assurance (QA) department. I've been pushing this issue rather strongly here at work as some of the work that we are doing is rather complex and relies on ad hoc testing of the sites we're building. Naturally, this is not an acceptable solution and a proper QA department (or person) who can institute an automated testing program should greatly improve the reliability of our products and increase our development speed. However, until we get someone to fill this position, I've been looking into alternatives.

One thing I've been considering is exploring Design by Contract. If you're not familiar with it, Design by Contract is a way of designing systems where each component specifies exactly what it accepts and what it will produce. This is the 'contract' between the client and server. Any code that violates the contract immediately generates useful error messages that can be used to track down and punish the offenders. Further, one can simply turn off the module to ensure that this does not affect the performance of production code.

I've never actually used this technique and it was my intention of downloading the modules and start testing them. Unfortunately, the link on the CPAN appears to be broken. I've also checked http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?request=search (a great CPAN mirror) to no avail. Until such time that I get a tarball to install and test with, can anyone offer suggestions or thoughts about using this? I know that many here do not care for Bondage and Discipline in code, but we're working on some rather large projects that are becoming unmanageable.

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[tilly]

If you are having trouble finding Class::Contract, you can go here and download it directly. You should also check out clemburg's Test::Unit as well as other testing related modules.

[jackdied]

I've used Test::Unit, and really like it. One of the nice things about perl is that it is very good language for writing self-testing routines in.

When you can, have the tests run outside the production environment. This isn't doable for everything, but offload as much as you can to 'make test' and 'make check' kinda tests.

Another good place to test modules is when they are loaded. Have modules register with a central module to announce themselves, when they call GateKeeper::register() use the caller(0) information to perform any runtime tests on the newly loaded module

package GateKeeper;
use strict;
my $package_list = {};
sub register {
  my ($package) = caller();

  perform_tests($package); # ensure all required subs are defined

  $package_list->{$package} = $package->cvs_version();  # cvs_version(
+) sub is tested in perform_tests
}

# other subs to query cvs version info and other fun stuff

Someday I plan on posting a more complete version of registration and testing of virtual interfaces to PM, but today isn't going to be that day.

-jackdied

[MZSanford]

When working with Toxic substances (e.g. Production without QA), i suggest that the development group take some time and read some of the QA literature, so they can write better self-tests.

I have to say, i write a fair amount of code, and write my own self-tests, but i have found that a seperate QA person finds more bugs, because they do not have a suspicion of where they may hide. But, when i noticed this trend, i took the time to trudge through Code Complete, which, dispite it's age, was pretty good. Since this, i have started looking to Other QA books, and i think that most developer's, especially the ones without QA, should take the time to read at minimum some sort of online QA test info.



# why does cent have to be US ?
my $two = $euro/100;

---

i had a memory leak once, and it ruined my favorite shirt.