Technical Blog

Sander Verhagen is a lead software engineer and architect, and the proprietor of Totaal Software. This blog was established in December 2013 as an outlet to showcase small code snippets, share great finds from the web and mailing lists, related to (Java) software development.

A lot of bad practices exist in software development. When focusing on testing, specifically unit and integration testing, there are still plenty of them. This discusses a few bad practices regarding logging. I am providing 6 rules for effective and useful logging in your tests, plus a library that can help with that.

Read more: 6 Rules for Effective Logging In Unit Tests

Another update got released for the mp3 Browser plugin for Joomla. This version was tested with Joomla 4.0.0-alpha2 and is believed appropriate for use with Joomla versions 3 and 4 (Release Notes). This version is now using the browser's default HTML5 player, using legacy Dewplayer as the fallback. A new version can be downloaded here.

After much too long, an update got released for the mp3 Browser plugin for Joomla. This version has a few small but nice improvements (Release Notes) but it is mostly a service release for compatibility with newer versions of Joomla and PHP (7.0). A new version can be downloaded here.

Today StageRace was open sourced, to allow existing customers (and the general public) to continue the useful life of StageRace for their purposes.

Read more: StageRace Open Sourced

Today we announce Emcee, available at https://emcee.online/, in a collaboration between Totaal Software and Squins IT Solutions. Emcee is a public beta, and free to use. Master the ceremony of maintaining and updating (software) systems. The ideas behind Emcee are simple: if you manage (software) systems that require maintenance, let the users of these systems know before, during and after the maintenance.

Read more: Announcing Emcee - https://emcee.online

According to Wikipedia, unit testing is a method by which individual units of source code (…) are tested to determine whether they are fit for use. “Fit for use,” is a very broad concept, and for unit tests it typically corresponds to how the author-developer in question looks at their implementation. Better tests are less tied to the implementation, but they nonetheless provide validation of an implementation against someone’s view of the desired behavior. Sometimes, though, it’s also behavior of the developer that we want to validate, using tools like Checkstyle or test coverage tools. I see also a distinct other class of validations, the ones where a unit test validates code constructs against agreements in the team. I’m specifically talking about code constructs that are locally relevant, so not the ones that the software industry has an opinion about, and probably has (better) tools for also. These are the ones where we crafted our own validations, some of which might qualify as “poor man’s”.

Read more: Unit Testing the Developer