Changes between Initial Version and Version 1 of Ticket #41
- Timestamp:
- 11/30/07 09:57:46 (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #41 – Description
initial v1 1 1 We 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 2 2 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. 3 This 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. 4 Some other frameworks are mentioned in [http://www.sesp.cse.clrc.ac.uk/Publications/tools_report_2006/node11.html this report]. 4 5 5 6 So 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.