JUnit essais suite, en phases: Toutes @Before, puis tout @Test, puis tout @After

Question

Je voudrais un coureur JUnit qui exécute toutes les méthodes @Before, puis toutes les méthodes @test, puis toutes les méthodes de @After.

Voici comment mon système fonctionne-Tests. Les méthodes @Before sont gérées, pour configurer les données de test et les scénarios. L'application est lancée. Ensuite, les méthodes @test sont exécutées avec l'application en cours d'exécution en arrière-plan. Ces méthodes peuvent @test modifier les données ou de répondre à la demande. Ensuite, le cadre attend l'application pour terminer. Par la suite, les méthodes de @After sont exécutés pour vérifier les résultats du test.

Je l'utilise déjà des annotations JUnit, des méthodes d'affirmation et d'autres différents bits. Mais je ne peux pas comprendre comment utiliser junits coureurs pour exécuter les méthodes d'essai de cette façon. Je ne pouvais pas faire des têtes ni queues de l'interface « Ordinateur » dans JUnit 4.8 ou comprendre comment appliquer des règles à ce sujet.

Answer 1

Ce n'est pas ce que fait JUnit. JUnit a une philosophie de conception qui met l'accent sur les tests unitaires indépendants. En tant que tel, il est un cadre naturel pour les tests du système. Qu'est-ce que vous voulez faire se intègre parfaitement dans TestNG (qui, comme un objectif de conception tente d'enjamber les tests unitaires et système).

Dans le JUnit @Before et @After sont exécutés avant et après chaque test. Vous pouvez caser ce genre de chose dans JUnit en utilisant une suite, références tous vos tests et est responsable de toute l'installation et le démontage, donc les méthodes @BeforeClass et @AfterClass de la suite s'exécuter avant et après la suite, qui, si vous organisez correctement pourrait être tous vos tests système.

Il y a beaucoup de défis organisationnels dans le code quand il est grand avec l'approche JUnit, donc je vous suggère de considérer et d'un cadre alternatif si c'est la plus grande partie de ce que vous voulez faire.

Answer 2

Je pense que vous pouvez résoudre ce problème en faisant une seule méthode d'essai réelle, que seulement les appels sont vos tests réels, que vous ne déclarez pas cCes.

Un peu comme:

@Before
public void beforeTest(){}

@After
public void afterTest(){}

@Test
public void test(){
    test1();
    test2();
    test3();
}

public void test1(){}

public void test2(){}

public void test3(){}