Antichesse (o ^ω^ o)
Exemple d'utilisation des tests paramétrés en TestNG avec les DataProvider :
import static org.assertj.core.Asserstions.assertThat;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class ExempleTest {
private PrimeNumberChecker primeNumberChecker = new PrimeNumberChecker();
@DataProvider(name = "test1")
static Object[][] primeNumbers() {
return new Object[][] {{2, true}, {6, false}, {19, true}, {22, false}, {23, true}};
}
// This test will run 5 times since we have 5 parameters defined
@Test(dataProvider = "test1")
void testPrimeNumberChecker(Integer inputNumber, Boolean expectedResult) {
assertThat(primeNumberChecker.validate(inputNumber)).isEqualTo(expectedResult);
}
}
Edit : Pitest marche avec TestNG finalement ! Il faut rajouter ceci au plugin (info que j'ai trouvée dans la conf Gradle d'une application Android mais pas dans la doc officielle) :
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>${version.pitest}</version>
<configuration>
<testPlugin>testng</testPlugin>
</configuration>
</plugin>Merci à @Animal et @Kysofer qui m'ont accompagnée très tard cette nuit sur Framatalk.org ! #BestBuddiesEver
Depuis hier je me casse les dents sur Pitest dont j'ai parlé à deux reprises ici et ici. Pour faire simple un client m'a demandé de le mettre en œuvre sur nos projets mais impossible de le faire marcher :'(
Comme ce soir tout le monde est couché depuis 1h30 et que j'ai l'esprit frais, je me suis dit que j'allais réessayer mais en changeant ma démarche. Cette fois-ci je prendrai un projet sur internet et qui fonctionne puis j'en modifierai sa configuration pour la faire converger vers celle de mon projet jusqu'à ce qu'elle pète.
Conclusion : Pitest ne fonctionne pas avec TestNG (et j'ai essayé toutes les versions majeures de la 6.1.1 conseillée par le site de Pitest jusqu'à la 7.3.0, dernière version en date).
Bref, cela faisait quelques temps que le couple TestNG + AssertJ me posait problème dans le sens où TestNG était moins bien pris en charge par certains framework et je vais a priori devoir faire un retour arrière pour le couple JUnit Jupiter + AssertJ (oui je conserve AssertJ, plus jamais les assertions de JUnit, viva la fluent-expressive API d'AssertJ).
Add a @KnownIssue annotation for TestNg tests that already have a related bug on Jira, and they will be skipped until it is resolved.
La communauté TestNG est prodigieuse. Le principe est le suivant :
- Lorsque vous avez un bug vous créez un ticket et un test reproduisant ce bug.
- Tant que le ticket est ouvert, le test - s'il échoue - ne plantera pas votre build.
- Si le test passe mais que le ticket est encore ouvert, alors le build va planter, vous forçant donc à fermer le ticket.
Cette annontation à ajouter en supplément du @Test vous garantira disposer d'un issues tracker toujours synchro avec l'état réel de votre code base.
Le problème : comment initialiser les attributs en @Mock avec TestNG et non JUnit ?
Avec les nouvelles versions de TestNG
import org.mockito.Mock
import org.mockito.MockitoAnnotations
import org.testng.annotations.BeforeMethod
class MonTest {
@Mock
private var classToMock:ClassToMock
@BeforeMethod
fun setUp() {
MockitoAnnotations.openMocks(this)
}
@Test
fun `my test should check something`() {
// ...
}
}Avec les anciennes versions de TestNG
import org.mockito.Mock
import org.mockito.MockitoAnnotations
import org.testng.annotations.BeforeMethod
class MonTest {
@Mock
private var classToMock:ClassToMock
@BeforeMethod
fun setUp() {
MockitoAnnotations.initMocks(this)
}
@Test
fun `my test should check something`() {
// ...
}
}