Comment tester au mieux le code Java?

Se moquer est un bon moyen de simuler des tests système dans des tests unitaires; en remplaçant (se moquant) les ressources dont dépend l'autre composant, vous pouvez effectuer des tests unitaires dans un environnement "de type système" sans avoir besoin d'avoir le système entier construit pour le faire.

En ce qui concerne vos questions spécifiques: généralement, vous ne devriez pas utiliser de tests unitaires pour tester les fonctions privées; s'ils sont privés, ils sont privés à la classe. Si vous avez besoin de tester quelque chose, testez une méthode publique qui utilise cette méthode privée pour faire quelque chose. Éviter les effets secondaires qui peuvent être potentiellement problématiques est mieux fait en utilisant soit un environnement de test complet (qui peut facilement être effacé à un état "vierge") ou en utilisant la moquerie, comme décrit ci-dessus. Et le test des interfaces se fait en testant les méthodes d'interface.

Tout d'abord, si vous avez déjà un grand système qui n'a pas de tests unitaires, et que vous envisagez d'en ajouter, permettez-moi de donner quelques conseils généraux.

En maintenant le système et en travaillant avec lui, vous connaîtrez probablement déjà les zones du système qui ont tendance à être les plus gênantes, qui ont tendance à changer souvent et qui ont tendance à ne pas beaucoup changer. Si vous ne le faites pas, vous pouvez toujours consulter les journaux de contrôle de source (vous utilisez le contrôle de source, non?) pour trouver où la plupart des corrections de bugs et modifications sont concentrées. Concentrez vos efforts de test sur ces classes et méthodes. Il existe une règle générale appelée 80/20 rule qui est applicable à toute une série de choses, ceci étant l'une d'entre elles.

Il dit que, en moyenne, vous devriez être en mesure de couvrir 80 pour cent des cas d'infraction en faisant seulement 20% du travail. Autrement dit, en écrivant des tests pour seulement 20% du code, vous pouvez probablement attraper 80% des bogues et des régressions. C'est parce que la plupart du code fragile, du code couramment modifié et du code le plus offensant ne représentent que 20% de la base de code. En fait, c'est peut-être encore moins.

Vous devriez utiliser junit pour ce faire et vous devriez utiliser quelque chose comme JMock ou une autre bibliothèque moqueuse pour vous assurer que vous testez isolément. Pour les tests de système / les tests d'intégration, c'est-à-dire les tests pendant qu'ils travaillent ensemble, je peux recommander FitNesse. J'ai eu une bonne expérience avec elle dans le passé. Il vous permet de écrivez votre test dans un navigateur Web en utilisant des mises en page simples de type table, où vous pouvez facilement définir vos entrées et vos sorties attendues. Tout ce que vous avez à faire est d'écrire une petite classe de sauvegarde appelée Fixture, qui gère la création des composants.

Les fonctions privées seront testées lorsque les fonctions publiques qui les appellent. Votre test de la fonction publique se soucie seulement que le résultat renvoyé est correct.

Lorsque vous traitez avec une API (vers d'autres paquets ou URL ou même vers un fichier/réseau/base de données), vous devez vous en moquer. Un bon test unitaire devrait s'exécuter en quelques millisecondes et non en quelques secondes. Se moquer est la seule façon de le faire. Cela signifie que les bogues entre paquets peuvent être traités beaucoup plus facilement que les bogues logiques au niveau fonctionnel. Pour Java easymock est un très bon framework moqueur.

Vous pouvez jeter un oeil sur cette liste: Outils pour les tests de régression / automatisation des tests d'une application java centrée sur la base de données? pour une liste d'outils intéressants.

Comme vous semblez déjà utiliser Junit de manière intensive, cela signifie que vous êtes déjà "testé infecté", c'est un bon point...

D'après mon expérience personnelle, la chose la plus difficile à gérer, ce sont les données. Je veux dire, contrôler très intensément les données agaisnt que les tests sont exécutés.

Les listes d'outils données précédemment sont utiles. D'après mon expérience personnelle, ce sont les outils que je trouve utiles:

Mocking - Mockito est une excellente implémentation et possède des techniques intelligentes pour vous assurer que vous n'avez qu'à vous moquer des méthodes qui vous intéressent vraiment.

Test de base de données - DBunit est indespendable pour la configuration des données de test et la vérification des interactions de base de données.

Stress testing - Jmeter - une fois que vous voyez passé l'interface graphique légèrement maladroite ce est un outil très robuste pour la mise en place de scénarios et l'exécution de tests de résistance.

En ce qui concerne l'approche générale, commencez par essayer de faire exécuter des tests pour les "chemins heureux" habituels via votre application, ceux-ci peuvent constituer une base pour les tests de régression et les tests de performance. Une fois cela terminé, vous pouvez commencer à examiner les cas périphériques et les scénarios d'erreur.

Bien que ce niveau de test devrait être secondaire à un bon test unitaire.

Bonne chance!