Literature
We will mainly be using Algorithms 4/E. by Robert Sedgewick & Kevin Wayne: Algorithms 4/E. Author site. Addison Wesley, 2011, Edition 4. (ISBN 9780321573513) Book site. (You need a copy of this book.)

Course info
-
Module: Algorithms and Data structures (ALDA)
-
Semester: 3
-
Credits: 5
-
Teachers: Richard van den Ham (HAMR02) & Pieter van den Hombergh (HOMB02),
Additional resources
-
A nice book with all kind of practical examples:
Taschenbuch der Algorithmen
or: Algorithms Unplugged -
The famous video lectures from: MIT.
Alda Run
Do not abuse annotations in tests.
Disabling coverage by means of some annotation has become trendy. Although it may have
has its place in production code (which we doubt, see remarks below), it is not meant
to defeat our teacher tests. Therefore, before we allow your code in our 'test arena' we
disable such annotations, because we see that although the spirit might be willing,
the flesh is sometimes weak, as in: 'it might be used for code that is not @Generated
by some framework or IDE'. Since we have no time to write a full fledged parser,
we simply comment the annotations by means of a one line sed script and a loop.
for f in $(grep -Prl '@Generated' ${arena}/src/main/java --include "*.java");do
sed -i 's#@Generated#//@Generated#;s#@NoTeacherTestCoverage#//@NoTeacherTestCoverage#' $f;
done
The script does not modify you code in the repository, it is applied before the tests are run. The project is copied to a ramdisk for speed and avoidance of disk wear. After the test run the resulting reports are copied to the publication server.
-
The best way to improve your coverage is to remove the code that is not required by the business. It is bad style to implement equals and hash code just for testing.
-
You not always need equals and hashcode, and if its only purpose is tests, then use the assertJ facilities to test the relevant fields with getters, like field by field comparison.
-
If your class is immutable (only final fields) then equals and hashcode might be useful if you want to use the instances as keys in a hashmap. If not, you typically do not need equals and friends, and comparable or a comparator might have its use. That also allows mapping by means of a SortedMap<K,V>, with TreeMap<K,V> as the first implementation that comes to mind.
-
If you really want the comfort of equals in your test code, use a custom
static boolean equals(my, other)
method in your test code, that does what your equals would do. With a few tricks you can even reuse the IDE generated code by replacingthis
withmy
.
boolean equals(Student my, Student other){
// No need for null test or type test as per normal equals(Object)
if (my==null && other != null ) return false; // This is what Objects.equals(a,b) does too
if (my!=null && other == null ) return false;
if (my==other) return true;
// we can now do method invocations and field test, because both are non-nill
if (!Objects.equals(my.getBirthDay(),other.getBirthDay())) return false;
// for the primitive fields
if (my.studentNumber == other.studentNumer ) return true;
// etc
}
and use it in your own assert method.
void studentAssertEquals(Student a, Student b) {
if (!equals(a,b)){
throw new AssertionError(String.format("expected student a=%s and b=% to be equal but they were not.",a,b));
}
}
-
During development having a toString and equals and hashcode might be useful, but throw them out (== best) or comment them (potential technical debt) when the business does not need them. If the methods were generated, then dropping them is no real loss and the IDE will gladly re-generate them when needed.
-
In a real project, having code that is not tested or used is a technical debt, because the assumption might be that such code is well defined business wise (as in which fields to consider or how to format) without proper requirement and proof. I have had the same situation too in projects and simply dropped the methods that are not demanded by the business, or made sure that the business code uses the result.
-
-
For those cases where equals and hashcode are defined for (hash)mapping (use the final fields only) the test recipe in PRC2 is well defined. You might want to add that to your test-toolbox.
-
If you find a business case (==test case) that uses the api only and does cover your uncovered code, you can of course suggest to include such test code in out teacher test suite.
Tip
|
When debugging and testing, a useful toString() is invaluable.
|
The test results of the students assigment, including test and optional coverage reports as well as the teachers tests can be found per topic in the following places:
Alda Run Rules
All testing as described below is on best effort basis. Things may break when running alien (that is: your) code.
The student repositories are regularly checked for a new code revision.
-
The student code (and test-code) is compiled. On any compiler error, the compiler output is published then STOP.
-
The student tests are run on the students code. If there are errors, the error report is published then STOP.
-
A coverage test run is performed with the code and test code above. The resulting coverage report is published.
-
If all tests are green in the above and the code coverage lies above the threshold, the teachers tests are run.
-
The teacher’s tests are combined with the student’s code and compiled. On any compiler error, the the compiler output is published then STOP.
-
The teacher’s tests are run on the students code. If there are any errors, the error report is published then STOP.
-
If there are no errors in the previous step, a coverage test run is done and a coverage report is published.
-
The goal of the exercise is to pass the teacher’s tests with no errors. The winner is that student that meets the goal in the earliest date-time. The date-time used is the svn commit time.