gradle pitest plugin
1.15.0
Das Plugin bietet die Möglichkeit, einen Mutationstest durchzuführen und eine Mutationsabdeckung eines Abschlusses auf Basis von Abschlüssen mit PIT zu berechnen.
Fügen Sie Gradle-Pitest-Plugin in die plugins -Konfiguration in Ihrem build.gradle hinzu. Gradle-Datei:
plugins {
id ' java ' // or 'java-library' - depending on your needs
id ' info.solidsoft.pitest ' version ' 1.15.0 '
}plugins {
id( " java " ) // or "java-library" - depending on your needs
id( " info.solidsoft.pitest " ) version " 1.15.0 "
}Rufen Sie Gradle mit Pitest -Aufgabe an:
gradle pitest
Nach den Messungen wird ein von PIT erstellter Bericht in ${PROJECT_DIR}/build/reports/pitest verzeichnis platziert.
Optional lassen Sie es vom Build abhängen:
build . dependsOn ' pitest 'tasks.build {
dependsOn( " pitest " )
} Beachten Sie, dass bei der Herstellung pitest von einer anderen Aufgabe abhängig ist, sie mit Namen bezeichnet werden muss. Andernfalls wird Gradle pitest für die Konfiguration und nicht die Aufgabe auflösen.
"The plugins Way" hat einige Einschränkungen. Als primäres Repository für das Plugin ist es auch das zentrale Repository (auch bekannt als Maven Central), es ist auch möglich, das Plugin mit "The Generic Way" zu Ihrem Projekt hinzuzufügen:
buildscript {
repositories {
mavenCentral()
// Needed only for SNAPSHOT versions
// maven { url 'https://oss.sonatype.org/content/repositories/snapshots/' }
}
dependencies {
classpath ' info.solidsoft.gradle.pitest:gradle-pitest-plugin:1.15.0 '
}
}buildscript {
repositories {
mavenCentral()
// Needed only for SNAPSHOT versions
// maven {
// url = uri("https://oss.sonatype.org/content/repositories/snapshots/")
// }
}
dependencies {
classpath( " info.solidsoft.gradle.pitest:gradle-pitest-plugin:1.15.0 " )
}
}Wenden Sie das Plugin an:
apply plugin : ' java ' // or 'java-library' - depending on your needs
apply plugin : ' info.solidsoft.pitest ' apply (plugin = " java " ) // or "java-library" - depending on your needs
apply (plugin = " info.solidsoft.pitest " ) Das Pitest -Plugin muss nicht zusätzlich konfiguriert werden, wenn Sie JUNIT 4. Die Anpassung erfolgt im pitest -Block:
pitest {
targetClasses = [ ' our.base.package.* ' ] // by default "${project.group}.*"
pitestVersion = ' 1.15.0 ' // not needed when a default PIT version should be used
threads = 4
outputFormats = [ ' XML ' , ' HTML ' ]
timestampedReports = false
}Idiomatische und tragbare Konfiguration:
pitest {
targetClasses.set( setOf ( " our.base.package.* " )) // by default "${project.group}.*"
pitestVersion.set( " 1.15.0 " ) // not needed when a default PIT version should be used
threads.set( 4 )
outputFormats.set( setOf ( " XML " , " HTML " ))
timestampedReports.set( false )
} Ausgehend von Gradle 8.1 kann die einfache Eigenschaftszuweisung zum Konfigurieren von Plugin (anstelle der set() -Methode) verwendet werden:
pitest {
targetClasses = setOf ( " our.base.package.* " ) // by default "${project.group}.*"
pitestVersion = " 1.15.0 " // not needed when a default PIT version should be used
threads = 4
outputFormats = setOf ( " XML " , " HTML " )
timestampedReports = false
} Die Konfiguration in Gradle ist der reale Groovy -Code, der alle Zuordnungen sehr intuitiv macht. Alle nach Gruben erwarteten Werte sollten als entsprechende Typen übergeben werden. Es gibt nur einen wichtigen Unterschied. Für die Parameter, bei denen PIT eine COMA -Trennungsliste von Zeichenfolgen in einer Gradle -Konfiguration erwartet, sollte eine Liste von Zeichenfolgen verwendet werden (siehe outputFormats im obigen Beispiel).
Überprüfen Sie die Pit -Dokumentation für eine Liste aller verfügbaren Befehlszeilenparameter. Das erwartete Parameterformat in einer Plugin -Konfiguration kann aus Pitestpluginextsion entnommen werden.
Um das Leben zu erleichtern, werden taskClasspath , mutableCodePaths , sourceDirs , reportDir , verbosity und pitestVersion automatisch vom Plugin festgelegt. Zusätzlich können sourceDirs , reportDir , verbosity und pitestVersion von einem Benutzer überschrieben werden.
Für das Gradle -Plugin sind einige Parameter spezifisch:
testSourceSets - Definiert Testquellsätze, die von PIT verwendet werden sollten (standardmäßig Quellensets.test, können jedoch Integrationstests in einem anderen Quellsatz hinzufügen)mainSourceSets - Definiert Hauptquellensätze, die von PIT verwendet werden sollten (standardmäßig Quellensets.main)mainProcessJvmArgs - JVM -Argumente, die bei der Start des Hauptgrubenprozesses verwendet werden sollen; Notieren Sie sich, dass Pit selbst weitere Java -Prozesse für die Ausführung von Mutationstests startet, und normalerweise sollte jvmArgs verwendet werden, um beispielsweise die maximale Speichergröße zu erhöhen (siehe Nr. 7).additionalMutableCodePaths - Zusätzliche Klassen zu mutieren (nützlich für Integrationstests mit Produktionscode in einem anderen Modul - siehe #25)useClasspathFile - Ermöglicht das Übergeben zusätzlicher Klassenpath als Dateiinhalt (nützlich für Windows -Benutzer mit vielen Klassenpath -Elementen, die standardmäßig deaktiviert sind)fileExtensionsToFilter - Bietet die Möglichkeit, zusätzliche Dateierweiterungen von Pit ClassPath zu filtern (siehe #53)Zum Beispiel:
pitest {
.. .
testSourceSets = [sourceSets . test, sourceSets . integrationTest]
mainSourceSets = [sourceSets . main, sourceSets . additionalMain]
jvmArgs = [ ' -Xmx1024m ' ]
useClasspathFile = true // useful with bigger projects on Windows
fileExtensionsToFilter . addAll( ' xml ' , ' orbit ' )
}pitest {
.. .
testSourceSets.set( listOf (sourceSets.test.get(), sourceSets.getByName( " integrationTest " )))
mainSourceSets.set( listOf (sourceSets.main.get(), sourceSets.getByName( " additionalMain " )))
jvmArgs.set( listOf ( " -Xmx1024m " ))
useClasspathFile.set( true ) // useful with bigger projects on Windows
fileExtensionsToFilter.addAll( " xml " , " orbit " )
}PIT führt Tests in einem JVM aus, das unabhängig von dem von Gradle verwendeten JVM zum Ausführen von Tests verwendet wird. Wenn Ihre Tests einige Systemeigenschaften erfordern, müssen Sie sie an Boxen weitergeben, da das Plugin dies nicht für Sie tut:
test {
systemProperty ' spring.test.constructor.autowire.mode ' , ' all '
}
pitest {
jvmArgs = [ ' -Dspring.test.constructor.autowire.mode=all ' ]
}tasks.test {
systemProperty( " spring.test.constructor.autowire.mode " , " all " )
}
pitest {
jvmArgs.set( listOf ( " -Dspring.test.constructor.autowire.mode=all " ))
} Wie in #170 intellij idee berichtet, zeigt Warnungen vor dem Festlegen der endgültigen Felder (der faulen Konfiguration) in build.gradle . Es ist kein echtes Problem, da Gradle diese Anrufe intern abfängt und stattdessen einen Setter verwenden. Dennoch können Menschen, die es vorziehen, keine (weniger) Warnungen auf Kosten weniger lesbarer Code zu haben, stattdessen Setzer verwenden, z. B.:
testSourceSets . set([sourceSets . test, sourceSets . integrationTest])
mainSourceSets . set([sourceSets . main, sourceSets . additionalMain])
jvmArgs . set([ ' -Xmx1024m ' ])
useClasspathFile . set( true ) // useful with bigger projects on Windows
fileExtensionsToFilter . addAll( ' xml ' , ' orbit ' )Gradle-Pitest-Plugin kann in Multi-Modul-Projekten verwendet werden. Die Abhängigkeit von Gradle-Pitest-Plugin sollte der Buildscript-Konfiguration im Stammprojekt hinzugefügt werden, während das Plugin in allen Unterprojekten angewendet werden muss, die mit PIT verarbeitet werden sollten. Ein Beispielausschnitt aus Build.gradle für das Root -Projekt:
// in root project configuration
plugins {
id ' info.solidsoft.pitest ' version ' 1.15.0 ' apply false
}
subprojects {
apply plugin : ' java '
apply plugin : ' info.solidsoft.pitest '
pitest {
threads = 4
if (project . name in [ ' module-without-any-test ' ]) {
failWhenNoMutations = false
}
}
} // in root project configuration
plugins {
id( " info.solidsoft.pitest " ) version " 1.15.0 "
}
subprojects {
apply (plugin = " java " )
apply (plugin = " info.solidsoft.pitest " )
pitest {
threads.set( 4 )
if (project.name in setOf ( " module-without-any-test " )) {
failWhenNoMutations.set( false )
}
}
} Es ist möglich, den Pitest-Bericht für das Multi-Modul-Projekt mit Plugin info.solidsoft.pitest.aggregator zu pitestReportAggregate . Das Root -Projekt muss ordnungsgemäß so konfiguriert sein, dass pitestReportAggregate verwendet wird:
// in root project configuration
plugins {
id ' info.solidsoft.pitest ' version ' 1.15.0 ' apply false
}
apply plugin : ' info.solidsoft.pitest.aggregator ' // to 'pitestReportAggregate' appear
subprojects {
apply plugin : ' java '
apply plugin : ' info.solidsoft.pitest '
pitest {
// export mutations.xml and line coverage for aggregation
outputFormats = [ " XML " ]
exportLineCoverage = true
timestampedReports = false
.. .
reportAggregator { // since 1.9.11 - extra results validation, if needed
testStrengthThreshold . set( 50 ) // simpler Groovy syntax (testStrengthThreshold = 50) does not seem to be supported for nested properties
mutationThreshold . set( 40 )
maxSurviving . set( 3 )
}
}
} // in root project configuration
plugins {
id( " info.solidsoft.pitest " ) version " 1.15.0 "
}
apply (plugin = " info.solidsoft.pitest.aggregator " )
subprojects {
apply (plugin = " java " )
apply (plugin = " info.solidsoft.pitest " )
pitest {
outputFormats.set( setOf ( " XML " ))
timestampedReports.set( false )
exportLineCoverage.set( true )
.. .
reportAggregator {
testStrengthThreshold.set( 50 )
mutationThreshold.set( 40 )
maxSurviving.set( 3 )
}
}
} Nach der Ausführung pitest pitestReportAggregate -Aufgaben wird der aggregierte Bericht in das Verzeichnis ${PROJECT_DIR}/build/reports/pitest platziert.
Es ist möglich, den Code in verschiedenen Unterprojekten zu mutieren. Gradle ist intern nicht auf Output -Verzeichnis aus einem anderen Teilprojekt angewiesen, sondern erstellt Glas und verwendet Klassen daraus. Für die Grube sind dies zwei verschiedene Sätze von Klassendateien. Um es zu ermöglichen, müssen sowohl mainSourceSets als auch additionalMutableCodePaths definiert werden. Zum Beispiel:
configure(project( ' :itest ' )) {
apply plugin : ' info.solidsoft.pitest '
dependencies {
implementation project( ' :shared ' )
}
configurations { mutableCodeBase { transitive false } }
dependencies { mutableCodeBase project( ' :shared ' ) }
pitest {
mainSourceSets = [project . sourceSets . main, project( ' :shared ' ) . sourceSets . main]
additionalMutableCodePaths = [configurations . mutableCodeBase . singleFile]
}
}configure( listOf (project( " :itest " ))) {
apply (plugin = " info.solidsoft.pitest " )
dependencies {
implementation(project( " :shared " ))
}
val mutableCodeBase by configurations.creating { isTransitive = false }
dependencies { mutableCodeBase(project( " :shared " )) }
pitest {
mainSourceSets.set( listOf (project.sourceSets.main.get(), project( " :shared " ).sourceSets.main.get()))
additionalMutableCodePaths.set( listOf (mutableCodeBase.singleFile))
}
}Die oben genannte Art und Weise, wie das Gradle -Team empfohlen wird, aber in bestimmten Fällen sollte die einfachere Lösung auch funktionieren:
configure(project( ' :itest ' )) {
apply plugin : ' info.solidsoft.pitest '
dependencies {
implementation project( ' :shared ' )
}
pitest {
mainSourceSets = [project . sourceSets . main, project( ' :shared ' ) . sourceSets . main]
additionalMutableCodePaths = project( ' :shared ' ) . jar . outputs . files . getFiles()
}
}configure( listOf (project( " :itest " ))) {
apply (plugin = " info.solidsoft.pitest " )
dependencies {
implementation(project( " :shared " ))
}
pitest {
mainSourceSets.set( listOf (project.sourceSets.main.get(), project( " :shared " ).sourceSets.main.get()))
additionalMutableCodePaths.set(project( " :shared " ).task( " jar " ).outputs.files)
}
}In der Suite für Funktionstests ist eine minimale Arbeit mit Multi-Project-Build verfügbar.
Test -Plugins werden verwendet, um verschiedene Testrahmen als JUNIT4 zu unterstützen.
Beginnend mit dieser Version wurde die für die Verwendung der PIT mit JUNIT 5 erforderliche Konfiguration zu Folgendem vereinfacht:
plugins {
id ' java '
id ' info.solidsoft.pitest ' version ' 1.15.0 '
}
pitest {
// adds dependency to org.pitest:pitest-junit5-plugin and sets "testPlugin" to "junit5"
junit5PluginVersion = ' 1.0.0 ' // or 0.15 for PIT <1.9.0
// ...
}plugins {
id( " java " )
id( " info.solidsoft.pitest " ) version " 1.15.0 "
}
pitest {
// adds dependency to org.pitest:pitest-junit5-plugin and sets "testPlugin" to "junit5"
junit5PluginVersion.set( " 1.0.0 " )
}Bitte beachten Sie . Pit 1.9.0 erfordert Pitest-Junit5-Plugin 1.0.0+. Junit Jupiter 5.8 (Junit-Plattform 1.8) erfordert Pitest-Junit5-Plugin 0,15+, während 5.7 (1.7) 0,14 benötigt. Stellen Sie die rechte Plugin -Version für JUNIT 5 -Version fest, die in Ihrem Projekt verwendet wird, um Laufzeitfehler zu vermeiden (wie "noSuchMethoderror: 'java.util.Optional org.junit.platform.commons.util.Annotationutils.Findannotation (java.lang.class, java.lang.lang.lang.klang.class, booolan).
Das minimale Arbeitsbeispiel für Junit 5 ist in der Suite für Funktionstests verfügbar.
Für das Mischen von JUNIT 5 mit anderen Pit -Plugins können Sie diesen Abschnitt in meinem Blog -Beitrag lesen.
Um Pit -Plugins zu aktivieren, reicht es aus, sie der Pitest -Konfiguration im Buildscript -Verschluss hinzuzufügen. Zum Beispiel:
plugins {
id ' java '
id ' info.solidsoft.pitest ' version ' 1.15.0 '
}
repositories {
mavenCentral()
}
dependencies {
pitest ' org.example.pit.plugins:pitest-custom-plugin:0.42 '
}plugins {
id( " java " )
id( " info.solidsoft.pitest " ) version " 1.15.0 "
}
repositories {
mavenCentral()
}
dependencies {
pitest( " org.example.pit.plugins:pitest-custom-plugin:0.42 " )
}Das minimale Arbeitsbeispiel ist in der Suite für Funktionstests verfügbar.
Bitte beachten Sie. In Gradle-Pitest-Plugin <1.5.0 musste die pitest Konfiguration im buildscript Bereich für das Stammprojekt erstellt werden. Bitte beachten Sie. Beginnend mit PIT 1.6.7 wird nicht mehr erforderlich, um testPlugin -Konfigurationsparameter festzulegen. Es ist auch im Gradle -Plugin veraltet.
Jede standardmäßige Gradle-Pitest-Plugin-Version verwendet eine vordefinierte Pit-Version. Normalerweise die neueste veröffentlichte Version von PIT, die zum Zeitpunkt der Veröffentlichung einer Plugin -Version verfügbar ist. Es kann durch die Verwendung von pitestVersion -Parametern in einem pitest -Konfigurationsverschluss überschrieben werden.
Bitte beachten Sie, dass es in einigen Fällen bei der Verwendung nicht Standard -Grubenversionen einige Probleme geben kann.
Wenn nicht anders angegeben, verwendet Gradle-Pitest-Plugin 1.9.x standardmäßig PIT 1.9.x, 1.7.x Pit 1.7.x usw. Die minimal unterstützte Pit-Version beträgt 1.7.1.
Beginnend mit der Version 1.7.0 Gradle-Pitest-Plugin ist Gradle 6.4 erforderlich. Die neueste Version mit der Unterstützung von Gradle 5.x (5.6+) beträgt 1,6.0. Die aktuelle Version wurde automatisch mit Gradle 6.4, 6.9.1 und 7.4.2 unter Java 11 getestet. Die Tests mit Java 11+ sind auf die kompatiblen Versionen von Gradle und PIT beschränkt.
Die experimentelle Unterstützung für Java 17 kann mit 1,7,0+ getestet werden.
Beginnend mit der Version 1.3.0 erfordern die produzierten Binärdateien Java 8 (als JDK, das zum Ausführen eines Gradle -Builds verwendet wird). Die Unterstützung von Java 17 LTs, die im September 2021 mit Gradle-Pitest-Plugin 1.9.0 veröffentlicht wurden, ist jedoch veraltet (siehe Nr. 299).
In der ChangeLog -Datei finden Sie eine detailliertere Liste der Änderungen im Plugin selbst.
Gradle bietet keine integrierte Möglichkeit, die Plugin-Konfiguration über die Befehlszeile zu überschreiben, aber dafür kann Gradle-Override-Plugin verwendet werden.
Nach dem angewandten Gradle-Override-Plugin in Ihrem Projekt ist es möglich:
./gradlew pitest -Doverride.pitest.reportDir=build/pitReport -Doverride.pitest.threads=8
Notiz. Der Mechanismus sollte für String- und numerische Eigenschaften gut funktionieren, aber es gibt Einschränkungen bei der Unterstützung von Listen/Sätzen/Karten und Booleschen Werten.
Weitere Informationen finden Sie unter Projektwebseite.
Gradle-Pitest-Plugin verwendet standardmäßig eine entsprechende Pit-Version (mit derselben Nummer). Das Plugin wird nur dann freigegeben, wenn interne Änderungen vorliegen oder sich auf Änderungen der neueren Grubenversion einstellen müssen. Es gibt einen speziellen Mechanismus, um die neueste Pit -Version (z. B. eine Bugfix -Version) zu verwenden oder die Grube bei erkannten Problemen herabzustufen. Um eine Standardversion zu überschreiben, reicht es aus, die Eigenschaft pitestVersion in den pitest -Konfigurationsverschluss festzulegen.
pitest {
pitestVersion = ' 2.8.1-the.greatest.one '
}pitest {
pitestVersion.set( " 2.8.1-the.greatest.one " )
}Wenn Fehler festgestellt werden, wenn die neueste verfügbare Version des Plugins mit einer neueren Grubenversion verwendet wird, wecken Sie bitte ein Problem.
Das Platzieren von Pit -Berichten direkt in ${PROJECT_DIR}/build/reports/pitest kann mit timestampedReports configuration -Eigenschaft aktiviert werden:
pitest {
timestampedReports = false
}pitest {
timestampedReports.set( false )
}Gelegentlich kann es nützlich sein, eine Ausführung des Gradle-Pitest-Plugins oder eine PIT-Ausführung selbst (z. B. NPE in PIT) zu debuggen, um einen vernünftigen Fehlerbericht bereitzustellen.
Die Ausführung von Gradle-Pitest-Plugin kann durch das Hinzufügen -Dorg.gradle.debug=true zur Befehlszeile aus der Ferne debuggiert werden.
Da die PIT jedoch als separater Prozess zur Debugug seiner Ausführung gestartet wird, müssen die folgenden Argumente zur Plugin -Konfiguration hinzugefügt werden:
pitest {
mainProcessJvmArgs = [ ' -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 ' ]
}pitest {
mainProcessJvmArgs.set( listOf ( " -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 " ))
}Kurze Antwort lautet: nicht direkt. Aufgrund einiger Inkompatibilitäten zwischen "Standard" -Stand -Java -Anwendungen und Android -Java -Anwendungen im Gradle unterstützt das Plugin die später nicht. Glücklicherweise gibt es eine Android -Gabel des Plugins von Karol Wrótniak, die eine modifizierte Version bietet, die Android -Anwendungen unterstützt (aber andererseits funktioniert es nicht mit Standard -Java -Anwendungen).
Gradle-Pitest-Plugin 1.5.0 entspannte sich schließlich die Art und Weise, wie (wo) die pitest Konfiguration platziert wurde (Nr. 62), was auch Abschaltungswarnungen in Gradle 6+ erzeugte. Diese Änderung ist nicht rückwärts kompatibel und als Ergebnis muss manuelle Migration vorgenommen werden - siehe die Versionshinweise. Dies betrifft nur das Projekt mit externen benutzerdefinierten Plugins.
Wichtig . Da das Junit 5 -Plugin für PIT definitiv das beliebteste ist, gibt es eine vereinfachte Weise, wie es mit junit5PluginVersion konfiguriert werden kann (was definitiv empfohlen wird ). Sehen Sie sich meinen Blog -Beitrag an, um herauszufinden, wie Sie migrieren können (es löst auch das Kompatibilitätsproblem mit 1.5.0+).
verbosity mit Pit 1.7.1) Aus dem Repository geklonten Gradle-Pitest-Plugin kann mit Gradle-Befehl erstellt werden:
./gradlew build
Der einfachste Weg, ein Glas mit lokalen Änderungen in einem anderen Projekt sichtbar zu machen, besteht darin, es in das lokale Maven -Repository zu installieren:
./gradlew install
Es gibt auch grundlegende Funktionstests mit dem Nebeltest, die mit:
./gradlew funcTest
Gradle-Pitest-Plugin wurde von Marcin Zajączkowski mit Hilfe von Mitwirkenden geschrieben. Der Autor kann direkt per E -Mail kontaktiert werden: MSZPAK ATT WP DOTT PL. Es gibt auch Marcins Blog: Solid Soft - Arbeitscode reicht nicht aus.
Das Plugin hat sicherlich einige Fehler und fehlende Funktionen. Sie können mit einem Problemverfolger gemeldet werden. Es ist jedoch oft eine bessere Idee, zuerst Fragen an die Pit -Mailing -Liste zu senden.
Das Plugin ist unter den Bestimmungen der Apache -Lizenz, Version 2.0, lizenziert.
