Compare testee actual results versus expected results
Repeat steps 1-3 for all specified public methods
Note: The software test "comparison" can be basic (print that allows a visual compare) or more sophisticated (e.g., showing "test passes", "test fails").
We may have the prettiest code in the world, but one blocker bug can make our code unusable
In the software field, unusable code causes delays and headaches
In coursework, unusable code results in scores of zero -- in fact, it is better to submit code 25% done with zero blocker bugs than code 99% done with one blocker bug
The happy news is we can easily avoid blocker bugs.
We just need to to do things:
Check and recheck that housekeeping items match what is expected -- e.g., required package/sub-directory names, class names, class headers, method headers, constructor headers
Graders and object will be using/testing our objects from "other" directories (and importing our files as needed) so we want to do similar. Otherwise, there is a good chance we'll miss bugs that they will hit (and these could be "blocker bugs").
If we put our test code in another directory (apart from our model/domain) then we will exercise/test required "imports" etc of our code.
By domain/model we mean our data structures (e.g. dynamic arrays, linked lists, trees, etc).
Testing with primitives (e.g. integers, strings, doubles) is an okay way to get started testing. But see "lessons learned" on testing with "proper objects".
class DynamicArrayTest {
test_get_usingStrings() {
let nm1 = 'Asha';
let nm2 = 'Kofi';
let dynamic = DynamicArray.newEmpty();
dynamic.add(nm1);
dynamic.add(nm2);
var result, expected;
result = dynamic.get(0);
expected = nm1;
this.show(result.toString());
this.show(expected.toString());
result = dynamic.get(1);
expected = nm2;
this.show(result.toString());
this.show(expected.toString());
//we could also test "first" and "last" the same way
}
//...
}