Archives par mot-clé : Java

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é.

Trier une liste en Java

Publié dans Snippet | Laisser un commentaire
Collections.sort(myList, new MyComparator());

public class MyComparator implements Comparator<MyObject> {
    @Override
    public int compare(MyObject o1, MyObject  o2) {
        if (o1.getInt() == o2.getInt()) {
            return 0;
        }
        if (o1.getInt() < o2.getInt()) {
            return -1;
        }
        return 1;
    }
}

Array en Java

Publié dans Snippet | Laisser un commentaire
String[] anArray = new String[10];
// OR
String[] anArray = {"Val1", "Val2"};

For-each ou for Iterator ?

Publié dans Java | Laisser un commentaire

En Java (comme dans plusieurs langages), il existe plusieurs manières de parcourir une liste d’éléments. Mais entre une boucle for classique, une boucle Iterator et un for-each, il existe quelques différences qu’il est de bon ton de connaître.

ilustration d'une boucle for

Continuer la lecture

Subtilité sur les classes abstraites Java

Publié dans Java | Laisser un commentaire

J’ai découvert une petite subtilité dans l’utilisation des classes abstraites aujourd’hui. Imaginons une interface Java qui est partiellement implémentée par une classe abstraite. Cette classe abstraite est assez naturellement étendue par une bonne vieille classe Java (la version française du POJO ;p). Jusqu’ici tout va bien.

Exemple 1 : héritage Java

Exemple 1 : héritage Java

Maintenant, imaginons que les méthodes implémentées dans notre classe abstraite, utilisent des méthodes implémentées seulement dans notre POJO. C’est là qu’est la subtilité (que j’annonce subtilement).
Continuer la lecture

Installer et Configurer Eclipse

Publié dans Java | Laisser un commentaire

Avant, je préférais avoir un seul Eclipse avec tous les plugins qui vont bien pour mes différents projets (Java, PHP, Android) et je jouais avec les workspace quand il fallait passer d’un projet à un autre. Aujourd’hui, j’ai l’impression qu’il vaut mieux avoir des Eclipses séparés selon l’utilisation :

  • Un optimisé pour les projets PHP,
  • Un autre pour les projets Java, OSGi
  • Et un autre pour Android. Même si pour ces deux derniers, j’aurai plutôt tendance à les mettre ensemble, à voir…

Du coup, j’ai une petite procédure d’installation / configuration et optimisation de mon IDE. La voici en résumé.
Continuer la lecture

Problèmes de mémoire ?

Java, memory leak et les erreurs de PermGen space

Publié dans Java | Laisser un commentaire

Trois articles (du même auteur) très intéressants sur les fuites mémoires en Java. A lire absolument, à tête reposée !

Base de données SQLite en ligne de commande sur Android

Publié dans Java | Laisser un commentaire

Imaginons que vous ayez un émulateur d’Android qui tourne actuellement sur votre machine, avec votre application en cours de développement, et que vous aimeriez voir ce qui se passe dans la base de données SQLite de votre application. Rien de plus simple grâce à quelques commandes SQLite.
Tout d’abord, il faut ouvrir votre shell favori (Sur Windows : Menu démarrer > Accessoires > Invite de commandes). Puis utilisez la commande suivante :

monShell>adb -e shell
#sqlite3 /data/data/android.societies/databases/societies.db
...
Ouverture SQLite
...
sqlite>... mes commandes SQLite ...

L’option -e signifie « l’émulateur actuellement ouvert. Donc si vous en avez plusieurs, ou si c’est un vrai téléphone qui est connecté à votre ordinateur : allez lire la doc pour voir comment faire. Comme ça, je dirais : adb devices pour avoir l’id des émulateurs et des téléphones en route. Puis adb -s [id séléctionné] shell. Après le comportement du shell peut varier sur un téléphone.

Quelques commandes SQLite utiles

  • .help: pour connaître la liste des commandes utiles !
  • .databases: listes des bases de données
  • .tables: liste les tables d’une base de données

Et bien sûr, toutes les commandes SQL de votre choix :

SELECT * FROM _table
DELETE FROM _table
REINDEX _table

Plus d’information

StringBuilder vs StringBuffer vs String.concat – done right | kaioa.com

Publié dans Java | Laisser un commentaire

D’après cet article StringBuilder vs StringBuffer vs String.concat – done right | kaioa.com (en anglais), il est plus avantageux en terme de performance d’utiliser StringBuilder à partir de Java 1.5 (ou StringBuffer pour les versions antérieures) que de concaténer des chaînes de caractères à coups de concat. Les chiffres sont assez parlant !

Each time you append something via ‘+’ (String.concat()) a new String is created, the old stuff is copied, the new stuff is appended, and the old String is thrown away. The bigger the String gets the longer it takes – there is more to copy and more garbage is produced.

Ce que l’on pourrait traduire par :

A chaque fois que l’on concatène à l’aide de String.concat(), une nouvelle instance de String est créée, l’ancienne étant copiée, accolée à la nouvelle, puis jetée. Plus longue est la chaîne de caractères et plus longtemps cela prendra. Donc plus on concatène, plus on créé du déchet.

De plus, le compilateur Java va transformer tout seul les concaténations manuelles avec des « + » ou des « line breaks » en utilisant des StringBuillder::append. Donc on peut utiliser sans problèmes cette écriture ! C’est de loin la plus lisible pour de petites chaînes de caractères. Quant aux autres : StringBuilder à la rescousse !

Voilà qui est bon à savoir 🙂

Pour aller un peu plus loin avec StringBuiler