Pouvons-nous utiliser JUNIT pour les Tests d'intégration automatisés?

J'ai utilisé JUnit pour faire beaucoup de tests d'intégration. Les tests d'intégration peuvent, bien sûr, signifier beaucoup de choses différentes. Pour plus de tests d'intégration au niveau du système, je préfère laisser les scripts piloter mon processus de test de l'extérieur.

Voici une approche qui fonctionne bien pour moi pour les applications qui utilisent http et les bases de données et je veux vérifier toute la pile:

1. Utilisez Hypersonic or H2 en mode in-memory en remplacement de la base de données (cela fonctionne mieux pour les ORM)
2. Initialiser la base de données dans @BeforeSuite ou équivalent (encore une fois: plus facile avec ORM)
3. Utilisez Jetty pour démarrer un serveur Web en cours de processus.
4. {[3] } chaque test, effacer la base de données et initialiser avec les données nécessaires
5. Utilisez JWebUnit pour exécuter des requêtes HTTP vers Jetty

Cela vous donne des tests d'intégration qui peuvent s'exécuter sans aucune configuration de base de données ou de serveur d'applications et qui exercent la pile à partir de http vers le bas. Comme il n'a aucune dépendance sur les ressources externes, ce test s'exécute très bien sur le serveur de construction.

Voici une partie du code que j'utilise:

@BeforeClass
public static void startServer() throws Exception {
    System.setProperty("hibernate.hbm2ddl.auto", "create");
    System.setProperty("hibernate.dialect", "...");
    DriverManagerDataSource dataSource = new DriverManagerDataSource();
    dataSource.setJdbcUrl("jdbc:hsqldb:mem:mytest");
    new org.mortbay.jetty.plus.naming.Resource(
             "jdbc/primaryDs", dataSource);


    Server server = new Server(0);
    WebAppContext webAppContext = new WebAppContext("src/main/webapp", "/");
    server.addHandler(webAppContext);
    server.start();
    webServerPort = server.getConnectors()[0].getLocalPort();
}

// From JWebUnit
private WebTestCase tester = new WebTestCase();

@Before
public void createTestContext() {
    tester.getTestContext().setBaseUrl("http://localhost:" + webServerPort + "/");
    dao.deleteAll(dao.find(Product.class));
    dao.flushChanges();
}

@Test
public void createNewProduct() throws Exception {
    String productName = uniqueName("product");
    int price = 54222;

    tester.beginAt("/products/new.html");
    tester.setTextField("productName", productName);
    tester.setTextField("price", Integer.toString(price));
    tester.submit("Create");

    Collection<Product> products = dao.find(Product.class);
    assertEquals(1, products.size());
    Product product = products.iterator().next();
    assertEquals(productName, product.getProductName());
    assertEquals(price, product.getPrice());
}

Pour ceux qui voudraient en savoir plus, j'ai écrit un article sur les tests d'intégration Embarqués avec Jetty et JWebUnit sur Java.net.

Lors de l'utilisation de Maven pour construire un projet, j'ai eu un peu plus de chance avec TestNG, car il a @BeforeSuite et @AfterSuite les opérations. Ce qui est utile car Maven n'exécutera pas le 'post-integration-test` si l'un des tests d'intégration échoue. Pas un problème avec Ant, donc j'utilise juste JUnit par préférence avec elle.

Dans les deux cas, la segmentation des tests comme le font TestNG et JUnit est également utile avec les tests d'intégration.

Dans notre travail ici, notre solution de test d'intégration comporte trois parties principales:

1. CruiseControl est le fondement de notre méthodologie d'intégration continue.
2. Notre configuration CruiseControl lance une construction de test rapide dans les 3 minutes suivant l'enregistrement de toute personne sur Subversion. Les tests qui se produisent ici sont "tout compile-t-il encore?"et" les tests unitaires passent-ils toujours?". JUnit est évidemment le principal facilitateur pour répondre à la deuxième questions.
3. Chaque heure, il lance une version plus grande qui construit l'aide en ligne et les installateurs que nous utilisons sur nos différentes plates-formes de déploiement. Cette étape vérifie les plus grandes questions de "avons-nous encore un produit déployable pour chacune de nos plates-formes cibles?"

Le résultat final est que la plupart des gens ici ne s'inquiètent jamais des tests d'intégration: cela arrive juste. Les tests unitaires, en revanche, sont la priorité de tous. JUnit facilite la construction de tests, bien que de bons tests nécessiteront toujours du temps de réflexion et de développement.

Oui, vous pouvez utiliser junit pour les tests d'intégration, mais cela dépend du type de test d'intégration dont vous avez besoin.

Tester un servlet:

• configuration du contexte et de la configuration du servlet
• faites les tests en utilisant des requêtes de servlet simulées (Spring prend en charge cela, mais vous pouvez également utiliser EasyMock ou vos propres mocks)

Tester une application de ressort:

• utilisez AbstractDependencyInjectionSpringContextTests pour configurer le contexte
• tester le câble haricots
• il existe également des sous-classes de AbstractDependencyInjectionSpringContextTests prenant en charge la gestion des transactions lors des tests avec une base de données.

Mais le Junit pur a sa limite. Le test des interfaces utilisateur est un cas typique. Vous pouvez utiliser selenium pour les applications Web, soapui pour les services Web ou d'autres outils appropriés.

Mais quoi que vous utilisiez, il devrait être possible de l'intégrer dans votre build continious (régulateur de vitesse, team city ou autre).

Définitivement! Nous utilisons une combinaison de tâches JUnit, ANT pour les exécuter et Hudson pour les tests d'intégration continus. Fonctionne comme un charme.

La suggestion dépend de votre application et de votre objectif.

J'ai écrit des tests d'intégration dans JUnit, mais j'ai aussi vu des gens utiliser HtmlUnit (JUnit extension), Selenium, Watir, Fit/Fitness, et même des outils commerciaux comme WinRunner et Silk.

Alors parlez-nous un peu plus de votre domaine et des objectifs de vos tests et vous pourrez probablement obtenir une meilleure réponse.

Il existe une très bonne extension pour JUnit appelée Jitr.

Jitr est un Runner de test d'intégration JUnit et il permet à vos tests d'intégration d'applications Web de s'exécuter facilement sur un conteneur Web léger dans la même JVM que vos tests.

Voir leur site pour plus de détails: http://www.jitr.org/

Mise à jour pour 2012: Alors que JUnit peut être utilisé (et bénéficie du support CI), JWebUnit et Selenium semblent manger le mindshare pour les tests d'intégration.

Je pense que les tests d'automatisation et d'intégration ne jouent pas bien ensemble. Le problème de base est configuration de l'environnement avant chaque test. Le test de type plus d'intégration plus grande configuration est nécessaire.

Mes réflexions sur l'automatisation des tests sur la couche d'intégration: http://blog.aplikacja.info/2012/03/whats-wrong-with-automated-integration-tests/