55 votes

Test d'Eclipse junit dans le même projet

Il s'agit d'une question relativement ouverte. Si j'ai construit une application dans un projet dans Eclipse et que je veux ensuite tester ce projet, dois-je créer le code JUnit dans le même projet ou créer un projet séparé. Par exemple...

ShopSystem peut-être le nom de mon projet principal - devrais-je créer un projet appelé disons, ShopSystemTest ?

En général, à quelle distance du dossier du projet principal le code de test doit-il être stocké ? Si je stocke le code de test dans le projet principal et que j'exporte ensuite le projet principal en tant que jar exécutable, le code de test sera emporté avec lui, ce qui n'est pas idéal...

Des suggestions ?

68voto

Henning Points 8776

Bien qu'il n'existe pas de méthode unique, l'approche habituelle consiste à conserver les tests unitaires dans le même projet.

Vous pouvez créer un deuxième dossier source (comme test ), où vous placez vos classes de test dans les mêmes paquets que les classes testées. Cela vous permet également de tester des classes privées de paquets sans inonder vos paquets sources principaux de classes de test.

La structure de votre dossier/package source ressemblerait alors à ceci :

-sources
   -main
       -my.package
             -MyClass.java
   -test
       -my.package
             -MyClassTest.java

Vous pouvez alors configurer votre build pour ne pas inclure le fichier test le dossier source lors de l'empaquetage du JAR.

21voto

Sean Patrick Floyd Points 109428

J'aime beaucoup la convention maven : Il y a un arbre source séparé pour main et test dans le même projet, le code main est déployé, le code test ne l'est pas. Les structures des paquets peuvent être (mais ne doivent pas être) identiques.

project
    src
        main
             java      // source files
             resources // xml, properties etc
        test
             java      // source files
             resources // xml, properties etc

Et en éclipse, quand vous choisissez new -> JUnit test case Si vous avez besoin de plus d'informations, il vous suffit de changer le dossier source en src/test/java et de laisser le paquetage suggéré tel quel.

(L'un des avantages de rester dans le même paquet est d'avoir accès aux membres protégés et aux membres du paquet, bien que ce ne soit pas un comportement de test unitaire "correct").


Mise à jour : Voici un peu de code pour illustrer mon dernier point :

Classe principale (dans src/main/java) :

package com.test;
public class Foo{

    static class Phleem{
        public Phleem(final String stupidParameter){
        }
    }

    String bar;
    protected String baz;
    protected Object thingy;

}

Classe de test (dans src/test/java) :

package com.test;
import org.junit.Test;

public class FooTest{

    @Test
    public void testFoo(){
        final Foo foo = new Foo();
        foo.bar = "I can access default-scoped members";
        foo.baz = "And protected members, too";
        foo.thingy = new Foo.Phleem("And I can access default-scoped classes");
    }

}

5voto

fastcodejava Points 22174

En général, vous avez -

/src/main/java   (for codes)

/src/test/java   (for tests)

4voto

Riduidel Points 13456

Considérons la méthode maven : dans un projet maven, les soruces sont organisées de la manière suivante

src
 |--main
 |     |--java
 |--test
       |--java

Votre code source se trouve dans src/main/java, votre code de test jUnit se trouve dans src/test/java, ce sont tous deux des dossiers sources (et par conséquent, vous pouvez placer votre code jUnit dans le même paquet que votre code Java, mais dans un dossier source différent).

L'intérêt est que pour le codage habituel, vos classes jUnit sont dans les paquets de code, mais lors de la création du jar, vous pouvez prendre les classes provenant uniquement de src/main/java et ne pas libérer vos tests.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X