While working on a legacy codebase, I had the chance to track down several random test failures: tests that worked or not depending on the time of the day, or depending on the order the test classes were running, etc.
Following are some such stories.
Test working in the IDE but failing with maven A test was failing as part of the Jenkins pipeline, but working fine locally from my IDE.
I once had the chance to speed up a test suite spanning multiple maven projects which took over 4 hours to run. The suite had around 8100 tests, many of which were integration tests using a Spring ApplicationContext. I managed to get this down to around 1h 20~30 mins, until other priorities prevented further reductions.
What follows is how this was achieved, and what things to watch out for.
Using a single JVM for the tests in a project The very first point is reusing forks in your maven-surefire-plugin and maven-failsafe-plugin configurations.
Instead of injecting values through method arguments and having to keep passing them wherever they are needed, consider creating an immutable object which encapsulates the logic and the needed values which are set on creation.
One benefit of this is improved readability. For instance, suppose we have two sets, one of valid codes for something (validCodes) and another of allowed dates (allowedDates). Compare:
if (isValidCode(validCodes, code) && isInAllowedDates(allowedDates, date)) { /* do something */ } vs.
After upgrading my machine at work, I had to migrate my configuration, and even remember some forgotten details about it. This is an attempt to document them for future reference:
Git config: Prerequisite: delta.
[user] email = work.email@here name = Cristian A. Ontivero [diff] algorithm = histogram [merge] conflictstyle = zdiff3 [pack] useSparse = true [pull] rebase = true [pager] diff = delta log = delta reflog = delta show = delta [interactive] diffFilter = delta --color-only [delta] features = line-numbers decorations whitespace-error-style = 22 reverse [delta "decorations"] commit-decoration-style = bold yellow box ul file-style = bold yellow ul file-decoration-style = none [core] bare = false compression = 9 editor = vim -c 'startinsert!
Because of how Spring’s implementation of AOP works (i.e. proxies), internal calls to a method in a proxied bean cannot be intercepted. This is a limitation of any AOP implementation using dynamic proxies. A way I’ve seen used to bypass this limitation is having an object with a dependency on itself, so that, for instance, internal calls to methods can also be cached when using a cache proxy1. Something like the following: