WeedCast 4.x Code Documentation

WeedCast 4.x
-Code Documentation, 8 July 2005-

JUnit:

The JUnit people have a nice article about the concept and how it works. If you want some details, that should pretty much cover everything you need to know in detail.

Behind the Scenes:

JUnit takes a look at classes that extend TestCase. It will then run the setUp() method. Here, we take the opportunity to set values for the model. We set up the weather file and soil conditions. Then JUnit will run each test. Primarily, JUnit will assert that things we expect to be true are actually true. For example

        assertEquals(-5.0, WildOat.SMTValue, .001);

This assertion checks to make sure the SMTValue of Wild Oat is -5.0. The .001 shows the tolerance. In some calculations, rounding error may cause the end values to be off slightly. For that reason, we provide a small allowance of error. If Wild Oat has a SMT value of something other than -5, that assertion will fail and the test will stop.

Now, if, after exhaustive research and field study, you determine that the SMT value for wild oat is actually -4.21456, you will need to change the value in the weed file and correct this test.

On the other hand, if this test fails and you don't recall anyone talking about changing this value, then something probably went wrong when we loaded the weed info. Perhaps someone accidentally changed that value.

Test Organization:

JUnit starts at the top of a class and runs the tests in sequence as it goes down. I've done my best to sort the tests in such a way that makes finding the root of the problem easy. A change in Growing Degree Days will mess up most of the tests. For example, the seedling heights will be wrong. However, it is fairly likely that the GDD test will be the first one to fail. Thus, the problem lies there, so don't go changing the height code if the problem is in GDD! That being said, sometimes the relationships are more complicated in all that math. So there are cases where the problem may lie elsewhere. Furthermore, it's impossible to make the tests completely comprehensive. For example, the seedling height tests don't test every weed.

In order to make finding errors that may compromise the accuracy of the model easy, be sure to run the tests before and after every code change you make.

Changing or Creating Tests:

When you do make a change to upgrade the accuracy of the model ;) you will have some tests fail. When you have assured that these new values are correct, you will want to update the tests with these values. Simply have the program print out the results of your changed functions and copy-paste them into the expected values of the appropriate test. If you are adding new functionality, be sure to create tests. I recommend duplicating an existing test and changing it to fit your needs. By convention, the tests are named:

        testnameOfYourFunction();

such as:

        testgetGDDCumulative();

They must start with the word "test" for Junit to recognise them as a test case.

Also, the model and weather data we use for most of the tests is the Mandan 2004 site. If possible, test your model using this information. If that isn't possible or if you want to do additional testing, you can create another model. WeedCast cleverly supports the existence of multiple model objects. This is handy since you can have a Mandan 2004 model with that specific soil type, tillage type, and weather data, in addition to a completely different site, at the same time. You'll want to set Main.theModel = yourModel; for the calculations; that is where the program looks for model information when it is doing calculations.

Graphical User Interface Tests:

As of right now, there are no tests for the GUI of Weedcast. All of the tests are focused on the accuracy of the model. It would probably be a good idea to do some tests for the gui though, but it isn't a high priority. You'd want to look into simulating mouseclicks for that.