Archives par mot-clé : jUnit

Architecture de tests en C++ avec Qt

Publié dans C / C++ | Laisser un commentaire

Si vous êtes développeur, je pense que vous avez surement entendu parler des tests unitaires (unit test) et j’espère que vous êtes convaincu de leur utilité ! Tester unitairement un morceau de code, c’est vérifier que celui-ci fait ce que l’on souhaite dans de multiples situations. Ensuite, on peut passer sereinement aux tests d’intégration qui vont tester plusieurs morceaux de codes (ou d’applications) entre eux. On peut encore raffiner avec des tests de performances, tests système, etc, etc… Tout dépend jusqu’où on souhaite aller.

Si on est capable de lancer régulièrement l’exécution de nos tests unitaires, alors on est capable de dire que notre code continue de fonctionner comme voulu malgré les mises à jours ou les refactoring. Cela n’empêche pas les erreurs ni les bugs, car on ne peut pas tester tout notre code unitairement, ou cela peut lamentablement planter lors de l’intégration. Néanmoins, on sait qu’une base solide « fonctionne comme prévu », ce qui facilite grandement la correction d’une erreur.

Pour des myriades de raisons :
tester son code c’est génial !!!

Des études prouvent même qu’une bonne gestion des tests permet au final de gagner du temps. Si vous n’y croyez pas, je vous invite sérieusement à reconsidérer votre opinion.

Ce que j’ai déjà vu dans certains environnements et ce que j’aimerai reproduire dans mon environnement Qt / C++, se résume ainsi :

Continuer la lecture

jUnit et les tests asynchrones

Publié dans Snippet | Laisser un commentaire

Où comment tester des méthodes asynchrones (avec listaner ou callback) en Java, par exemple avec jUnit. En fait c’est un moyen rapide et relativement sûr (quoique non conseillé pour du vrai code) de rendre une méthode synchrone.

Snippet

public class AsynchronousTest
{
    /**
    * Asynchronous helper
    */
    private CountDownLatch lock = new CountDownLatch(1);
    /**
    * Received data from the asynchronous call
    */
    private Object receiveddata;

    @Test
    public void testAsynchronousCall() throws Exception {
        Object parameters = null;
        myAsynchronousCall(parameters, new MyCallback() {
                @Override
                public void onSuccess(Object data) {
                    receiveddata = data;
                    lock.countDown();
                }
            });

        boolean releaseBeforeTimeout = lock.await(2000, TimeUnit.MILLISECONDS);
        // Check timeout
        if (!releaseBeforeTimeout) {
            // Do stuff
            fail("Timeout");
        }

        assertNotNull(receiveddata);
        // Other tests
    }
}

Explications

L’idée de base est la suivante :

  • On initialise un CountDownLatch à 1, c’est-à-dire à un seul usage. Chaque appel à CountDownLatch::countDow() représente une utilisation.
  • On exécute la méthode asynchrone. La fin de cette méthode appelle CountDownLatch::countDow(). Mais avant d’en arriver là, pendant que la méthode s’exécute…
  • On regarde si le CountDownLatch est à 0 (dans le cas où la méthode asynchrone a déjà terminé) ou on attend qu’il passe à 0 (c’est-à-dire que la méthode asynchrone s’est terminée), ou on attend jusqu’à la fin d’un timeout (temps défini après lequel on considère que l’exécution de la méthode a échoué.