Question

Dans notre projet, j'ai plusieurs que par exemple prendre tous les fichiers d'un répertoire et exécuter un test sur elle. Si je mets en œuvre une méthode dans le testEveryFileInDirectory cela apparaît TestCase comme un seul test qui peut échouer ou réussir. Mais je suis intéressé par les résultats sur chaque fichier. Comment puis-je écrire un TestSuite / de sorte que chaque <=> fichier apparaît comme un test séparé par exemple dans le TestRunner graphique d'Eclipse? (Codage d'une méthode de test explicite pour chaque fichier est pas une option.)

Comparez aussi la question ParameterizedTest avec un nom dans Eclipse TestRunner .

Était-ce utile?

La solution

Jetez un oeil à Tests paramétrés dans JUnit 4.

En fait, je l'ai fait il y a quelques jours. Je vais essayer d'expliquer ...

Tout d'abord construire votre classe de test normalement, comme vous où le test juste avec un fichier d'entrée. Décorez votre classe avec:

@RunWith(Parameterized.class)

Construire un constructeur qui prend l'entrée qui va changer dans chaque appel de test (dans ce cas, il peut être le fichier lui-même)

Ensuite, construire une méthode statique qui retourne un des tableaux Collection. Chaque tableau dans la collection contiendra les arguments d'entrée pour votre constructeur de classe par exemple le fichier. Décorez cette méthode avec:

@Parameters

Voici une classe exemple.

@RunWith(Parameterized.class)
public class ParameterizedTest {

    private File file;

    public ParameterizedTest(File file) {
        this.file = file;
    }

    @Test
    public void test1() throws Exception {  }

    @Test
    public void test2() throws Exception {  }

    @Parameters
    public static Collection<Object[]> data() {
        // load the files as you want
        Object[] fileArg1 = new Object[] { new File("path1") };
        Object[] fileArg2 = new Object[] { new File("path2") };

        Collection<Object[]> data = new ArrayList<Object[]>();
        data.add(fileArg1);
        data.add(fileArg2);
        return data;
    }
}

Consultez également cette exemple

Autres conseils

JUnit 3

public class XTest extends TestCase {

    public File file;

    public XTest(File file) {
        super(file.toString());
        this.file = file;
    }

    public void testX() {
        fail("Failed: " + file);
    }

}

public class XTestSuite extends TestSuite {

    public static Test suite() {
        TestSuite suite = new TestSuite("XTestSuite");
        File[] files = new File(".").listFiles();
        for (File file : files) {
            suite.addTest(new XTest(file));
        }
        return suite;
    }

}

JUnit 4

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class TestY {

    @Parameters
    public static Collection<Object[]> getFiles() {
        Collection<Object[]> params = new ArrayList<Object[]>();
        for (File f : new File(".").listFiles()) {
            Object[] arr = new Object[] { f };
            params.add(arr);
        }
        return params;
    }

    private File file;

    public TestY(File file) {
        this.file = file;
    }

    @Test
    public void testY() {
        fail(file.toString());
    }

}

Tests Junit 5 paramétrées

JUnit 5 des tests paramétrés soutenir ceci en permettant l'utilisation d'un procédé source de données :

@ParameterizedTest
@MethodSource("fileProvider")
void testFile(File f) {
    // Your test comes here
}

static Stream<File> fileProvider() {
    return Arrays.asList(new File(".").list()).stream();
}

JUnit 5 DynamicTests

JUnit 5 également des supports ce grâce à la notion d'un DynamicTest, qui doit être générée dans un @TestFactory, au moyen de la méthode statique dynamicTest.

import org.junit.jupiter.api.DynamicTest;
import org.junit.jupiter.api.TestFactory;
import static org.junit.jupiter.api.DynamicTest.dynamicTest;

import java.util.stream.Stream;

@TestFactory
public Stream<DynamicTest> testFiles() {
    return Arrays.asList(new File(".").list())
            .stream()
            .map((file) -> dynamicTest(
                    "Test for file: " + file,
                    () -> { /* Your test comes here */ }));
}

Les tests effectués dans votre IDE (IntelliJ ici) seront affichés comme ceci:

devrait être possible dans JUnit 3 en héritant de la TestSuite et méthode remplaçant pour lister les tests() fichiers et pour chaque retour une instance d'une sous-classe de qui prend le TestCase nom de fichier comme paramètre du constructeur et a un test méthode qui teste le fichier donné dans le constructeur.

Dans JUnit 4, il est peut-être encore plus facile.

Vous pouvez envisager d'utiliser JUnitParams bibliothèque , de sorte que vous auriez quelques options plus (propre):

@org.junit.runner.RunWith(junitparams.JUnitParamsRunner.class)
public class ParameterizedTest {

    @org.junit.Test
    @junitparams.Parameters(method = "data")
    public void test1(File file) throws Exception {  }

    @org.junit.Test
    @junitparams.Parameters(method = "data")
    public void test2(File file) throws Exception {  }

    public static File[] data() {
        return new File[] { new File("path1"), new File("path2") };
    }
}

@org.junit.runner.RunWith(junitparams.JUnitParamsRunner.class)
public class ParameterizedTest {

    @org.junit.Test
    @junitparams.Parameters(value = { "path1", "path2" })
    public void test1(String path) throws Exception {
        File file = new File(path);
    }

    @org.junit.Test
    @junitparams.Parameters(value = { "path1", "path2" })
    public void test2(String path) throws Exception {
        File file = new File(path);
    }
}

Vous pouvez voir plus échantillons de utilisation ici.

En plus sur les JUnitParams, pourquoi les tests paramétrés avec writting il est plus facile et plus lisible :

  

projet JUnitParams ajoute un nouveau coureur à JUnit et fournit beaucoup   plus facile et des tests lisibles paramétrées pour JUnit> = 4.6.

     

Principales différences à la norme coureur JUnit paramétrées:

     
      
  • plus explicite - params sont dans la méthode de test params, pas des champs de classe
  •   
  • moins de code - vous n'avez pas besoin d'un constructeur pour configurer les paramètres
  •   
  • vous pouvez mélanger avec des méthodes non param etr-paramétrés dans une classe
  •   
  • params peut être transmis sous forme de chaîne CSV ou d'une classe de fournisseur de paramètres
  •   
  • classe de fournisseur de paramètres peut avoir autant de paramètres fournissant des méthodes que vous voulez, de sorte que vous pouvez regrouper différents cas
  •   
  • vous pouvez avoir une méthode d'essai qui fournit des paramètres (pas de classes externes ou plus statique)
  •   
  • vous pouvez voir les valeurs réelles des paramètres dans votre IDE (dans paramétrées JUnit il n'y a que des nombres consécutifs de paramètres)
  •   

Si TestNG est une option, vous pouvez utiliser Paramètres avec DataProviders .

Chaque test de fichier individuel aura le résultat indiqué dans le rapport basé sur le texte ou l'interface utilisateur du plugin Eclipse TestNG. Le nombre de tests COMPTEUR compteront chacun de vos fichiers individuellement.

Ce comportement diffère de JUnit , où tous les résultats sont regroupées sous une entrée « théorie » et compter uniquement 1 test. Si vous souhaitez générer des rapports de résultat séparé JUnit, vous pouvez essayer paramétrées Tests .

Test et entrées

public class FileTest {

    @DataProvider(name="files")
    public File[][] getFiles(){
        return new File[][] {
            { new File("file1") },
            { new File("file2") }
        };
        // or scan a directory
    }

    @Test(dataProvider="files")
    public void testFile(File file){
        //run tests on file
    }
}

Exemple sortie

PASSED: testFile(file1)
PASSED: testFile(file2)

===============================================
    Default test
    Tests run: 2, Failures: 0, Skips: 0
===============================================

J'ai eu un problème similaire et a fini par écrire simple JUnit 4 runner qui permet med de générer dynamiquement des tests.

https://github.com/kimble/junit-test-factory

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top