gradle pitest plugin
1.15.0
O plug-in oferece a capacidade de realizar um teste de mutação e calcular uma cobertura de mutação de um projeto baseado em graduação com poço.
Adicione o Gradle-Pitest-Plugin à configuração plugins no seu arquivo build.gradle :
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 "
}Ligue para Gradle com tarefa Pitest:
gradle pitest
Após as medições, um relatório criado pelo PIT será colocado em ${PROJECT_DIR}/build/reports/pitest Directory.
Opcionalmente, faça depender da construção:
build . dependsOn ' pitest 'tasks.build {
dependsOn( " pitest " )
} Observe que, ao fazer pitest depender de outra tarefa, ele deve ser referido pelo nome. Caso contrário, o GRADLE resolverá pitest para a configuração e não a tarefa.
"The plugins Way" tem algumas limitações. Como o repositório principal do plug -in é o repositório central (também conhecido como Maven Central), também é possível adicionar o plug -in ao seu projeto usando "The Generic Way":
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 " )
}
}Aplique o plugin:
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 " ) O plug -in Pitest não precisa ser configurado adicionalmente se você usar o Junit 4. A personalização é feita no bloco pitest :
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
}Configuração idiomática e mais portátil:
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 )
} A partir do Gradle 8.1, a atribuição de propriedades simples pode ser usada para configurar o plug -in (em vez do método set() ):
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
} A configuração no Gradle é o código Groovy real que torna todas as atribuições muito intuitivas. Todos os valores esperados pelo PIT devem ser passados como tipos correspondentes. Existe apenas uma diferença importante. Para os parâmetros em que o Pit espera uma lista separada de strings em coma em uma configuração gradle, uma lista de strings deve ser usada (consulte outputFormats no exemplo acima).
Verifique a documentação do poço para obter uma lista de todos os parâmetros de linha de comando disponíveis. O formato de parâmetro esperado em uma configuração de plug -in pode ser retirado do pitestpluginextension.
Para facilitar a vida da taskClasspath , mutableCodePaths , sourceDirs , reportDir , verbosity e pitestVersion são automaticamente definidos pelo plug -in. Além disso, sourceDirs , reportDir , verbosity e pitestVersion podem ser substituídos por um usuário.
Existem alguns parâmetros específicos para o plug -in gradle:
testSourceSets - Define conjuntos de fontes de teste que devem ser usados pelo Pit (por fontes padrão.mainSourceSets - define os principais conjuntos de fontes que devem ser usados pelo Pit (por fontes padrão.Main)mainProcessJvmArgs - Argumentos da JVM a serem usados ao iniciar o processo principal do poço; Observe que o próprio Pit lança outros processos Java para execução de testes de mutação e geralmente jvmArgs devem ser usados, por exemplo, aumente o tamanho máximo da memória (consulte #7);additionalMutableCodePaths - Classes adicionais para muta (útil para testes de integração com código de produção em um módulo diferente - ver #25)useClasspathFile - Permite a passagem de ClassPath adicional como um conteúdo de arquivo (útil para usuários do Windows com muitos elementos de patê de classe, desativados por padrão)fileExtensionsToFilter - fornece capacidade de filtrar extensões de arquivo adicionais do Pit ClassPath (consulte #53)Por exemplo:
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 " )
}O PIT executa testes em uma JVM independente da JVM usada pelo GRADLE para executar testes. Se seus testes exigirem algumas propriedades do sistema, você precisará passá -las para o poço, pois o plug -in não fará isso por você:
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 " ))
} Conforme relatado no #170 Intellij Idea, exibe avisos sobre a definição de campos finais (da configuração preguiçosa) em build.gradle . Não é um problema real, pois a gradle intercepta internamente essas chamadas e usa um setter. No entanto, as pessoas que preferem não ter (menos) avisos ao custo de código menos legível podem usar os setters, por exemplo:
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 ' )O gradle-pitest-plugin pode ser usado em projetos de vários módulos. A dependência Gradle-Pitest-Plugin deve ser adicionada à configuração do BuildScript no projeto raiz, enquanto o plug-in deve ser aplicado em todos os subprojetos que devem ser processados com o PIT. Um snippet de amostra da Build.gradle localizado para o projeto raiz:
// 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 )
}
}
} É possível agregar o relatório Pitest para o projeto multimódulo usando o plug-in info.solidsoft.pitest.aggregator e a tarefa pitestReportAggregate . O projeto raiz deve ser configurado corretamente para usar pitestReportAggregate :
// 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 )
}
}
} Após a execução das tarefas pitest pitestReportAggregate , o relatório agregado será colocado no diretório ${PROJECT_DIR}/build/reports/pitest .
É possível mudar o código localizado em subproject diferente. A Gradle internamente não depende do diretório de saída de outro subprojeto, mas constrói Jar e usa classes dele. Para o Pit, esses são dois conjuntos diferentes de arquivos de classe; portanto, para que ele funcione, é necessário definir os mainSourceSets e additionalMutableCodePaths . Por exemplo:
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))
}
}O exposto acima é o caminho recomendado pela equipe Gradle, mas em casos específicos a solução mais simples também deve funcionar:
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)
}
}A compilação de vários projetos de trabalho mínima está disponível no conjunto de testes funcionais.
Os plug -ins de teste são usados para suportar diferentes estruturas de teste que o JUNIT4.
Começando com este lançamento, a configuração necessária para usar o poço com o Junit 5 foi simplificada para o seguinte:
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 " )
}Observe . O poço 1.9.0 requer pitest-junit5-plugin 1.0.0+. O JUNIT JUPITER 5.8 (Plataforma Junit 1.8) requer pitest-Junit5-Plugin 0,15+, enquanto 5,7 (1,7) requer 0,14. Defina a versão correta do plug -in para a versão Junit 5 usada em seu projeto para evitar erros de tempo de execução (como `Nosuchmethoderror: 'java.util.optional org.junit.platform.commons.util.annotationutils.findannotation (java.lang.class, java.lang.class.classl.findannotation (java.lang.lang), java.lang.classs.cl, boolean.lang.class, java.lang.class.class, boolean.
O exemplo mínimo de trabalho para o Junit 5 está disponível no conjunto de testes funcionais.
Para misturar o Junit 5 com outros plugins de pit, você pode ler esta seção na minha postagem no blog.
Para ativar os plugins do pit, basta adicioná -lo à configuração Pitest no fechamento do BuildScript. Por exemplo:
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 " )
}O exemplo mínimo de trabalho está disponível no conjunto de testes funcionais.
Observe. Na Gradle-Pitest-Plugin <1.5.0, a configuração pitest teve que ser criada no escopo buildscript para o projeto raiz. Observe. Começando com o Pit 1.6.7, não é mais necessário definir o parâmetro de configuração testPlugin . Também é descontinuado no plug -in gradle.
Toda versão Gradle-Pitest-Plugin por padrão usa uma versão predefinida do PIT. Geralmente, esta a mais recente versão lançada do Pit disponível no momento da liberação de uma versão do plug -in. Ele pode ser substituído usando o parâmetro pitestVersion em um fechamento de configuração pitest .
Esteja ciente de que, em alguns casos, pode haver alguns problemas ao usar versões não padrão do poço.
Se não for indicado de outra forma, o gradle-pitest-plugin 1.9.x por padrão usa o pit 1.9.x, 1.7.x usa o pit 1.7.x, etc. A versão mínima suportada é 1.7.1.
Começando com a versão 1.7.0 Gradle-Pitest-Plugin requer o Gradle 6.4. A versão mais recente com o suporte Gradle 5.x (5.6+) é 1.6.0. A versão atual foi automaticamente testada com o gradle 6.4, 6.9.1 e 7.4.2 sob Java 11. Os testes com Java 11+ são limitados às versões compatíveis de Gradle e Pit.
O suporte experimental para Java 17 pode ser testado com 1.7.0+.
Começando com a versão 1.3.0 Os binários produzidos exigem o Java 8 (como um JDK usado para executar uma construção gradle). No entanto, com o Java 17 LTS lançado em setembro de 2021, começando com o plugin 1.9.0 gradle-pitest, o suporte ao JDK <11 está depreciado (ver nº 299).
Consulte o arquivo Changelog para obter uma lista mais detalhada de alterações no próprio plug -in.
A GRADLE não fornece uma maneira interna de substituir a configuração do plug-in via linha de comando, mas a plugina gradle-override pode ser usada para fazer isso.
Após a aplicação de plugina gradle-override em seu projeto, é possível fazer seguintes:
./gradlew pitest -Doverride.pitest.reportDir=build/pitReport -Doverride.pitest.threads=8
Observação. O mecanismo deve funcionar bem para propriedades de corda e numéricas, mas existem limitações com o suporte a listas/conjuntos/mapas e valores booleanos.
Para mais informações, consulte a página da web do projeto.
Por padrão, o gradle-pitest-plugin usa uma versão do poço correspondente (com o mesmo número). O plug -in é liberado apenas se houver alterações internas ou for necessário ajustar as alterações na versão mais recente do poço. Existe um mecanismo dedicado para permitir usar a versão mais recente do poço (por exemplo, uma versão de bug) ou para rebaixar o poço em caso de problemas detectados. Para substituir uma versão padrão, é suficiente definir a propriedade pitestVersion no fechamento da configuração pitest .
pitest {
pitestVersion = ' 2.8.1-the.greatest.one '
}pitest {
pitestVersion.set( " 2.8.1-the.greatest.one " )
}Em caso de erros detectados quando a versão mais recente do plug -in disponível é usada com a versão mais recente do poço, por favor, aumente um problema.
Colocar os relatórios do PIT diretamente em ${PROJECT_DIR}/build/reports/pitest pode ser ativado com a propriedade de configuração timestampedReports :
pitest {
timestampedReports = false
}pitest {
timestampedReports.set( false )
}Ocasionalmente, pode ser útil depurar uma execução de Gradle-Pitest-Plugin ou uma execução em pit (por exemplo, NPE no PIT) para fornecer um relatório de erro sensível.
A execução do gradle-pitest-plugin pode ser remotamente depurada com adicionar -Dorg.gradle.debug=true à linha de comando.
No entanto, como o PIT é iniciado como um processo separado para depurar sua execução, os seguintes argumentos precisam ser adicionados à configuração do plug -in:
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 " ))
}Resposta curta é: não diretamente. Devido a algumas incompatibilidades entre os aplicativos Java "padrão" e os aplicativos Java Android no Gradle, o plug -in não suporta o posterior. Felizmente, existe um garfo Android do plug -in mantido por Karol Wrótniak, que fornece uma versão modificada que suporta aplicativos Android (mas, por outro lado, não funciona com aplicativos Java padrão).
O plugin gradle-pitest 1.5.0 finalmente relaxou como (onde) a configuração pitest foi colocada (#62), que também estava gerando avisos de depreciação no Gradle 6+. Essa alteração não é compatível com versões anteriores e, como resultado, a migração manual deve ser feita - consulte as notas de lançamento. Isso afeta apenas o projeto de projeto com plugins personalizados externos.
Importante . Como o plug -in do Junit 5 para o PIT é definitivamente o mais popular, começando com 1.4.7, existe uma maneira simplificada de como ele pode ser configurado com junit5PluginVersion (o que é definitivamente recomendado ). Veja minha postagem no blog para descobrir como migrar (ele também resolve o problema de compatibilidade com 1.5.0+).
verbosity introduzida com o pit 1.7.1) Gradle-Pitest-Plugin clonado do repositório pode ser construído usando o comando gradle:
./gradlew build
A maneira mais fácil de fazer um frasco com mudanças locais visíveis em outro projeto é instalá -lo no repositório local do Maven:
./gradlew install
Também existem testes funcionais básicos escritos usando o teste de nebulosa que podem ser executados com:
./gradlew funcTest
Gradle-Pitest-Plugin foi escrito por Marcin Zajączkowski com a ajuda de colaboradores. O autor pode ser contatado diretamente por e -mail: mszpak att wp dott pl. Há também o blog de Marcin disponível: Solid Soft - o código de trabalho não é suficiente.
O plug -in certamente tem alguns bugs e recursos ausentes. Eles podem ser relatados usando um rastreador de problemas. No entanto, geralmente é uma idéia melhor enviar uma pergunta para a lista de discussão primeiro.
O plug -in é licenciado nos termos da licença Apache, versão 2.0.
