Version 3 (modified by toby, 12 years ago) (diff)


The hope is that all sections of GSAS-II "model" code (as opposed to controller or view code in the MVC paradigm) will eventually have unit tests, as described below.

Design philosophy

The goal is that the unit tests will exercise as much possible code as can be managed. Unit tests are expected to change and expand as code is augmented. Unit tests have several roles:

  • to insure that module interfaces remain static, so that downstream code is not broken by changes in a module
  • to validate computations against independently derived values (from other software or reference materials)
  • to confirm that results are platform independent
  • to catch software bugs as code is augmented and adapted

Where possible, unit tests should be both comprehensive and quick.


Tests are to be included directly in the GSAS-II module by defining test functions. The test functions should be named to start with the string "test" and should not require any arguments. The should use assert or raise to report an unexpected result and should not print anything if the test succeeds. If the test requires more input than can comfortably be included in the module itself, the input should be placed in directory testinp\. If routines are used to generate this input, the generating routines can also be placed here.