I try to apply Pitest to an older project that relies on timezone settings. Some tests are specifically for daylight-saving issues, when certain days in a year have more or less than 24 hours in local time. I cannot change the code or the tests.
These tests fail with Pitest but run fine otherwise.
From what I see, JUnit/Surefire takes into account the global property user.timezone
that is set in Maven POM, but Pitest does not.
<properties>
<argLine>-Duser.timezone=Europe/Berlin</argLine>
<properties>
Also if set on command line directly as mvn verify -Duser.timezone=Europe/Berlin ...
it does not work.
Possible workarounds for me are:
- Exclude the affected test classes
- Set
TZ=Europe/Berlin
on system level
I would be happy to learn about other possibilities to set the timezone in a way that Pitest picks it up.
For completeness, this is my first approach to a Maven profile so that Pitests runs on mvn verify -P mutation-testing
:
<profile>
<id>mutation-testing</id>
<build>
<plugins>
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>1.8.0</version>
<executions>
<execution>
<goals>
<goal>mutationCoverage</goal>
</goals>
</execution>
</executions>
<configuration>
<timestampedReports>false</timestampedReports>
</configuration>
<dependencies>
<dependency>
<groupId>org.pitest</groupId>
<artifactId>pitest-junit5-plugin</artifactId>
<version>0.16</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
Maybe it is possible with the jvmArgs
configuration of Pitest? How?
Note that I am new to Pitest and mutation testing so maybe I do something stupid.
CodePudding user response:
In order to insert mutants, keep them isolated from each other and handle the infinite loops that mutations might cause, pitest has to run code in child processes.
Configutation can be passed to them using the jvmArgs
parameter.
<jvmArgs><value>-Duser.timezone=Europe/Berlin</value></jvmArgs>
Will set the timezone in all jvms that pitest launches.
As an aside, if your code makes decisions based on time and date it is usually a good idea to make this an explicit dependency of the code that can be inject (eg with a java.time.Clock
). This way tests can manipulate time in a fine grained manner, and do not need to rely on global settings.