Technical Manual

[ Return to Technical Manual Index ]

Test Plan




The purpose of this document is to outline the procedure that members of the Hydro Models team are supposed to follow to bring the object-oriented version of RHESSys into conformance with the output specified by the clients. The problem that the original, procedural version of RHESSys does not produce the output specified by the client is, at this time, still unresolved. Due to this discrepancy we will have to establish our own benchmarks for some of the test cases, as noted below. There are two phases to the test plan both detailed below.

Test Cases

The following chart maps test cases to a name and will be referred to throughout the rest of this document. The Test Name is just a number use to refer to a specific run of the model. The numbers also represent the priority of getting each test to pass. Low number implies high priority. The Command Line Parameters are the arguments to pass to RHESSys. The Compare Results With column lists the benchmark files. After a test run, compare the files produced from the run with those listed in the column. All files are in the test/hja directory. A 'Y' in the Phase 1 or Phase 2 column indicates that the test case currently conforms to the standards of the given phase as detailed below. All tests must be run form the test directory so that they can find the proper input files. The command lines in the table were supplied by the client for the purpose of testing the object-oriented version of RHESSys.

Test Name 

Command Line Parameters

Compare Results With

Phase 1

Phase 2


-t hja/hja.tec -w hja/world.single -b





 -b -p -z -h -t hja/hja.tec -w hja/ -r hja/flow_table.w2T -s 1.0 10.0








 -c 1 1 1 5502 -t hja/hja.tec.state -w hja/ -r hja/flow_table.w2T -s 1.0 10.0 -ed 1960 1 1 1






 -t hja/hja.tec.cut -w hja/ -r hja/flow_table.pixels.w3 -b -s 1.0 10.0





 -t hja/hja.tec -w hja/ -r hja/flow_table.pixels.w3 -b -s 1.0 10.0




-t hja/hja.tec -w hja/ -s 0.7 1.7 -b -p






-t hja/hja.tec -w hja/world.mzones -r hja/flow_table.mzones -s 1.0 10.0 -ed 1962 1 1 1 -b




(*) Denotes test runs for which we must establish our own benchmarks.
(1) As noted, this test is one for which we must establish our own benchmarks.  I did this by running our version of the old C code and comparing the output of this program to the output of our new C++ code.  Our code passes this test with one discrepancy.  It is on line 28 of the output file world_state.  Our code says that the file listed on the line is a stratum default file, which it is.  The old code output that this was a basin default file, which it isn't.  So I consider this a fix and say that we pass. <HANK HOFFMANN
(2) The file hja/result_basin.daily.6 was created from running the old version of rhessys with the command line associated with test 6.  Our C++ version of rhessys produces the same output that is produced by the old version, but neither version produces the output specified by the file hja/result_basin.mzones, which was provided by the client.  <HANK HOFFMANN

Phase 1

Phase 1 involves removing all the pointer errors. This phase involves getting RHESSys to exit each test case cleanly, that is, no segmentation faults, bus errors, etc. Start with test case 1. Make sure that test case i exits cleanly before moving on to test case i+1. If you fix a module i, recompile and run all tests 1 through i again. If you change a module and break cause a problem in one of the test cases that was marked as passing on the page above, it is your responsibility to fix it. After fixing a test case, mark it as conforming to phase 1 standards on the chart above. For phase 1, we should be able to find all these errors running rhessys in a debugger.

Phase 2

Unlike Phase 1, we will be working on the cases of Phase 2 in parallel. This makes marking the tests that pass Phase 2 all the more important. Again, after pushing a fix, it is your responsibility to ensure that everything that is marked as passing on the table above still passes.

For Phase 2 debugging it is suggested that you run the old C code in a debugger at the same time you are running the new C++ version. In this way you can step through both models and figure out where variables are being corrupted.

Testing the GUI

There is a command line test program written in C++ that can be used for testing the GUI. To test just the GUI, link to the command line test program and generate command lines from the GUI. The test program will spit back the parameters it was passed.

Integration and Testing

After all the model test cases pass, link the GUI to the model and use the GUI to generate the command lines given in the above table. The results from GUI generated runs should be identical to the results from command line runs. That is, the GUI should generate the same behavior shown in the table above.


Author: Hank Hoffmann