Eclipse, junit test dans le même projet

Ce qui est relativement question ouverte. Si j'ai créé une application dans un projet dans Eclipse et je veux tester ce projet, dois-je créer le JUnit code dans le même projet ou créer un projet distinct. Par exemple...

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

En général - comment "loin" si les tests de code de l'enregistrer dans le dossier de projet principal? Si je stocke le code de test dans le projet principal, puis exporter le projet principal comme un runnable jar il faudra le code de test, ce qui n'est pas idéal...

Suggestions?

InformationsquelleAutor david99world | 2010-08-26

67

Alors qu'il n'y a pas seulement le droit chemin, la démarche habituelle est de garder les tests unitaires dans le même projet.

Vous pouvez créer un deuxième dossier source (comme test), où vous mettez vos classes de test dans les mêmes paquets que les classes de test. Cela permet également de tester colis-privé, tandis que les classes ne pas inonder votre principale source de packages avec des classes de test.

Votre dossier source/la structure du package ressemblerait alors à ceci:
```
-sources
   -main
       -my.package
             -MyClass.java
   -test
       -my.package
             -MyClassTest.java
```
Vous pouvez ensuite configurer votre build de ne pas inclure le test dossier source lors de l'emballage du POT.

InformationsquelleAutor Henning
21

J'aime le maven convention de beaucoup de choses: Il y a une source distincte de l'arbre principal et de test dans le même projet, le code principal est déployé, le code de test n'a pas. Package structures peuvent être (mais n'ont pas à être) identiques.
```
project
    src
        main
             java      //source files
             resources //xml, properties etc
        test
             java      //source files
             resources //xml, properties etc
```
Et dans eclipse, lorsque vous choisissez new -> JUnit test case, il suffit de changer le dossier source dans src/test/java et de laisser le paquet suggéré que est.

(L'un des avantages de rester dans le même paquet est d'avoir accès aux protégés de package et de l'étendue de membres, mais ce n'est pas " bon " test de l'unité de comportement)

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;

}
```
De la 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");
    }

}
```
- "l'accès aux protégés de package et de l'étendue des membres" - pour avoir accès aux membres protégés, vous auriez à la sous-classe de la classe sous test. Ce que vous entendez est la possibilité d'accéder paquet d'étendue de classes, non?
- Oh, et les membres aussi, bien sûr, vous avez raison. J'ai utilisé par défaut-portée membres tellement rarement que j'ai parfois oublier qu'ils existent.
- Ouch! Je ne savais pas protected permis l'accès à d'autres classes du même package. Ok, ça efface les choses, merci.
- oui, l'ensemble de niveau d'accès concept est plutôt stupide. par exemple, il n'y a pas moyen de faire des paquets accessibles pour les sous-packages sans faire les classes publiques. scala a un bien meilleur système.
- Je suis d'accord. Si Java a été conçu aujourd'hui, privé serait peut-être le défaut, les protégés de permettre l'accès uniquement depuis les sous-classes, il y aurait une notion de sous-paquets, et final par défaut pour les classes, les variables locales et peut-être même des membres. Oh bien.
- finale serait par défaut? vous dire qu'il y aurait un mot-clé pour marquer des classes et des méthodes extensible? Je ne suis pas sûr si je veux pas que parce que vous avez le bug de l'API concepteurs de tous les temps s'il vous plaît ajouter le mot-clé à cette et cette méthode.
- Ainsi, il serait mis à la règle dans la conception et le document de l'héritage ou de l'interdire (Josh Bloch) à droite dans la langue. OMI, vous pouvez presque jamais d'étendre une classe bien qui n'a pas été conçu pour cela à partir du sol.
- Je sais, j'ai essayé d'étendre les Hibernate Validator une fois. J'ai renoncé à bientôt et ré-écrit la plupart de celui-ci...
InformationsquelleAutor Sean Patrick Floyd

Généralement vous ont -

/src/main/java   (for codes)

/src/test/java   (for tests)

InformationsquelleAutor fastcodejava

4

Considérer le maven : Dans un projet maven, soruces sont organisées de cette façon
```
src
 |--main
 |     |--java
 |--test
       |--java
```
Votre code source va dans src/main/java, votre junit test code va dans src/test/java, ils sont la source de dossier (et, en conséquence vous pouvez mettre votre jUnit code dans le même package que votre code Java, mais dans un autre dossier source).

L'intérêt est que pour habitude de codage, votre jUnit classes sont dans les paquets de code, mais sur le pot de création, vous pouvez prendre des cours à venir seulement de la src/main/java et relâchez pas vos tests.

InformationsquelleAutor Riduidel

Vous devez vous connecter pour publier un commentaire.