Getting code working (aka debugging) inevitably means understanding each discrete step in your code. Placing logging statements at strategic points allows the code to self-report on its internal state. An example would be:-
LOGGER.trace("ticket#{} using item {} from warehouse", ticket, removed);
The text output can be examined as part of unit tests and switched on or off as desired, so they can just be left in the source code. The log4j and slf4j libraries provide logging facilities, including them is just a matter of including in the maven pom.XML. Problems can occur as other libraries try to use their own logging libraries, an example for this project was with the log-capture maven plugin complaining about “multiple slf4j loggers”. Solved (after a lot of pondering and experiment) by adding some specific ‘when unit testing don’t use this logger” instructions in the pom.xml with a <classpathDependencyExcludes> element.
Check the pom.xml in the project for the full detail.
So seemingly after a lot of setting up we can move onto design, architecture and actually coding.