SWUG:Quality Control

From GO Wiki
Revision as of 14:22, 2 April 2008 by Cjm (talk | contribs) (New page: == Automated Testing == General principles: * ''all'' GO software must have an extensive test suite * all cvs/svn commits must pass the test suite * new capabilities must be accompanied...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Automated Testing

General principles:

  • all GO software must have an extensive test suite
  • all cvs/svn commits must pass the test suite
  • new capabilities must be accompanied by tests
  • all releases absolutely must pass every test

Perl APIs

Both go-perl and go-db-perl have extensive test suites in the standard perl style. To run them:

cd go-perl perl Makefile.PL make test

Note that go-db-perl test suite requires presence of a writeable database; if not present the suite will automatically pass. This facilitates simple CPAN installs.

Java APIs

The org.obo API underpinning OBO-Edit has several JUnit test suites. There is a JUnit master test that runs them all

We need to do more to ensure the tests are run regularly. See: this tracker item

  • TODO

Database building

This is somewhat ad-hoc. go-db-perl tests isolated parts of database building, but not the whole pipeline.

There is a mini-pipeline test, which tests a full build with the first 10k lines from every gene-association file:

cd go-dev/database/test make

AFAIK this is not run regulary.

  • TODO

OBO-Edit

There is currently no automated testing for the UI. This is quite difficult to do.

AmiGO

Web-apps are slightly easier to automatically test than standalone apps. We still need manual testing to see if everything looks OK etc. However, we can still do link checking and flow-of-control checking.

  • TODO - Seth, fill in hammer details here.

For example, for any linkouts to AmiGO, we should add these to the test suite and make sure they return valid html that contains the relevant information

Manual Testing

Automated testing form the first line of defense. Manual testing is still required, particularly for end-user apps.

Manual and automated testing can be intertwined. E.g. A link checker can pre-load a bunch of URLs into a single web page making it much easier for testers to look them over.

Documentation

  • Perl modules should have POD documentation -- this will show up when released on CPAN for example
  • Java should have javadoc & this should be auto-published

Code should obviously be commented.

Scripts should show USAGE info when called with no args or -h