testing run - Comment faire pour exécuter une seule classe de test sur gradle





specific execute (4)


Dans le cas où vous avez un projet multi-module:

disons que la structure de votre module est

root-module
 -> a-module
 -> b-module

et le test (testToRun) que vous cherchez à lancer est dans b-module, avec le chemin complet: com.xyz.b.module.TestClass.testToRun

Comme ici vous êtes intéressé pour exécuter le test dans b-module, vous devriez voir les tâches disponibles pour b-module.

./gradlew :b-module:tasks

La commande ci-dessus liste toutes les tâches dans b-module avec la description. Et dans le cas idéal, vous aurez une tâche nommée test pour exécuter les tests unitaires dans ce module.

./gradlew :b-module:test

Maintenant, vous avez atteint le point pour exécuter tous les tests dans b-module, enfin vous pouvez passer un paramètre à la tâche ci-dessus pour exécuter des tests qui correspondent au modèle de chemin certain

./gradlew :b-module:test --tests "com.xyz.b.module.TestClass.testToRun"

Maintenant, au lieu de cela si vous exécutez

./gradlew test --tests "com.xyz.b.module.TestClass.testToRun"

Il exécutera la tâche de test pour les deux modules a et b, ce qui pourrait entraîner un échec car il n'y a rien de correspondant au modèle ci-dessus dans un module.

Je suis nouveau à Gradle. J'utilise Gradle 1.10 et Ubuntu 13.

Je veux savoir s'il existe une commande pour exécuter une seule classe de test, similaire à 'testonly' dans SBT.




Vous pouvez faire gradle -Dtest.single=ClassUnderTestTest test si vous voulez tester une seule classe ou utiliser regexp comme gradle -Dtest.single=ClassName*Test test vous pouvez trouver plus d'exemples de classes de filtrage pour les tests sous cette section du lien 23.12. Tester




Pour exécuter une seule classe de test, la réponse d'Airborn est bonne.

En utilisant certaines options de ligne de commande, que vous trouverez here , vous pouvez simplement faire quelque chose comme ça.

gradle test --tests org.gradle.SomeTest.someSpecificFeature
gradle test --tests *SomeTest.someSpecificFeature
gradle test --tests *SomeSpecificTest
gradle test --tests all.in.specific.package*
gradle test --tests *IntegTest
gradle test --tests *IntegTest*ui*
gradle test --tests *IntegTest.singleMethod
gradle someTestTask --tests *UiTest someOtherTestTask --tests *WebTest*ui

À partir de la version 1.10 de Gradle, il est possible de sélectionner des tests en utilisant un filtre de test . Par exemple,

apply plugin: 'java'

test {
  filter {
    //specific test method
      includeTestsMatching "org.gradle.SomeTest.someSpecificFeature"

     //specific test method, use wildcard for packages
     includeTestsMatching "*SomeTest.someSpecificFeature"

     //specific test class
     includeTestsMatching "org.gradle.SomeTest"

     //specific test class, wildcard for packages
     includeTestsMatching "*.SomeTest"

     //all classes in package, recursively
     includeTestsMatching "com.gradle.tooling.*"

     //all integration tests, by naming convention
      includeTestsMatching "*IntegTest"

     //only ui tests from integration tests, by some naming convention
     includeTestsMatching "*IntegTest*ui"
   }
}



Notez qu'une différence clé entre SBT et Gradle est sa gestion des dépendances :

  • SBT : Ivy , avec une révision qui peut être donnée comme fixe (1.5.2, par exemple) ou comme dernière (ou dynamique).
    Voir " Dépendance d'Ivy "
    Cela signifie que le support du mécanisme "-SNAPSHOT" peut être problématique, même si Mark Harrah détaille ce sujet :

Il est vrai que le cache peut être confus, mais il n'est pas vrai qu'Ivy ne comprenne pas la résolution des snapshots. Eugene a expliqué ce point dans un autre fil, peut-être sur la liste des administrateurs. Il y a un problème avec la mise à jour automatique de sbt qui a été adressée en 0.12.

Ce que Ivy ne supporte pas, pour autant que je sache, c'est de publier des instantanés comme le fait Maven. Je crois l'avoir dit ailleurs, mais si quelqu'un veut améliorer la situation, je pense qu'il vaut mieux travailler avec l'équipe de Gradle pour réutiliser son code de gestion de la dépendance.

Juste pour que vous sachiez, les problèmes avec les dépendances d'instantané d'Ivy et de Maven étaient l'une des raisons pour lesquelles Gradle a finalement remplacé Ivy avec son propre code de gestion de dépendance. C'était une grande tâche, mais cela nous a apporté beaucoup de bonté.

Ce tweet mentionne que toute la situation pourrait évoluer dans le futur:

Mark a dit dans le passé qu'il était intéressé à utiliser Gradle au lieu de Ivy pour SBT.

(les deux outils peuvent apprendre les uns des autres )





testing gradle