Changes between Initial Version and Version 1 of Ticket #41


Ignore:
Timestamp:
11/30/07 09:57:46 (17 years ago)
Author:
VincentMcIntyre
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #41 – Description

    initial v1  
    11We need to know when we do something to the code that breaks existing functionality, i.e. we introduce a regression. The usual path for this is [http://en.wikipedia.org/wiki/XUnit unit testing]. There are lots of [http://www.testingfaqs.org/t-unit.html testing frameworks] available
    22
    3 This is difficult to do with scientific software because the answers each subroutine are not always possible to predict. Also, the only unit [http://funit.rubyforge.org/ test framework for FORTRAN] is aimed at FORTRAN-90, it doesn't handle FORTRAN-77.
     3This is difficult to do with scientific software because the answers each subroutine are not always possible to predict. Also, the only free unit [http://funit.rubyforge.org/ test framework for FORTRAN] is aimed at FORTRAN-90, it doesn't handle FORTRAN-77.
     4Some other frameworks are mentioned in [http://www.sesp.cse.clrc.ac.uk/Publications/tools_report_2006/node11.html this report].
    45
    56So the best we can do right now is "smoke tests" - read in some data files and process them with a shell (or perl) script that calls MIRIAD subroutines, and look for errors (or possibly for large differences). To do this we need to start collecting data files that exercise the various corners of the MIRIAD code. We should also collect any data files that give errors. Once the bugs that gave rise to the problem are fixed, we should be able to rerun those files at any time and see no errors.