Test Java en ligne niveau d'entrée. Test du programme, JUnit. Conditions préalables aux tests Java

Je crois que le développement de logiciels est plus qu'un travail. Je me considère comme un artisan qui essaie de s'améliorer chaque jour. Le moyen le plus « simple » d’y parvenir est de trouver de bons outils et de répondre aux questions suivantes :

• Quand dois-je utiliser Tool X ?
• Comment dois-je utiliser l’outil X ?

Les tests automatisés constituent une partie très importante du développement logiciel, mais il existe peu d'articles sur les blogs des programmeurs concernant les outils utilisés. Ce même article vous permettra de consulter ma « boîte à outils ». Je couvrirai 12 bibliothèques et frameworks que j'utilise pour écrire des tests unitaires et d'intégration, et fournirai des liens vers des pages qui vous aideront à comprendre comment les utiliser.

Regardons dans ma boîte à outils

Avant de pouvoir utiliser les outils décrits ci-dessous, vous devez configurer une version qui exécute automatiquement les tests d'intégration et unitaires. J'ai 2 notes sur ce sujet:

• Les tests d'intégration avec Maven décrivent comment nous pouvons configurer une version Maven avec des tests d'intégration et unitaires dans différents répertoires.
• Premiers pas avec Gradle : les tests d'intégration avec le plugin TestSets couvrent la même chose pour Gradle.

Vous êtes maintenant prêt à examiner de plus près mes outils. Je les ai divisés en catégories pour faciliter votre navigation.

Voici donc 12 outils que j'utilise pour l'intégration et les tests unitaires.

Exécution de tests

AssertJ fournit une API flexible pour écrire des assertions avec des messages d'erreur utiles, améliore la lisibilité du code de test et vous permet de transformer les tests en spécifications exécutables qui adhèrent au langage spécifique au domaine souhaité.

En plus:

• Utiliser Hamcrest dans les tests explique comment utiliser Hamcrest pour écrire des tests, ainsi que comment étendre ses capacités avec des modules personnalisés.
• Transformer les assertions en un langage spécifique au domaine explique comment créer des assertions personnalisées dans AssertJ.
• Rédaction de tests propres : remplacement des assertions par un langage spécifique au domaine. Explique pourquoi nous devrions remplacer les assertions standard de JUnit par les nôtres qui utilisent un langage spécifique au domaine.

Test du code d'accès aux données

Base de données rapide, utile pour écrire des tests d'intégration qui s'exécutent sur machine locale développeur.

Une extension de JUnit qui peut être utilisée pour initialiser la base de données à un état connu avant d'exécuter chaque test d'intégration et remplir la base de données avec les données nécessaires. DbUnit a ses inconvénients, mais il est très outil utile, qui vous permet de séparer les données de test et le code de test.

En plus:

• décrit les composants clés de DbUnit que vous devez connaître pour écrire des tests à l'aide de DbUnit.
• fournit cinq règles pour écrire les meilleurs tests de code d'accès aux données.

En cherchant des tâches de test pour les programmeurs Java, je suis tombé sur un site intéressant (les utilisateurs d'Avast ne devraient pas y aller, un cheval de Troie de script est détecté, d'autres vont apparemment bien) - http://www.betterprogrammer.com. Il teste les qualifications des programmeurs Java de la manière la plus simple, mais de manière automatique: proposant d'écrire plusieurs fonctions (méthodes) de complexité croissante et de copier le code dans la TextArea. Ensuite, le moteur du site fait quelque chose avec les tâches (pas moins qu'un test unitaire), calcule un certain indice de qualification basé sur les critères « vitesse-qualité » et donne la note finale sous la forme suivante :

Puis les questions commencent. J'ai moi-même programmé en Java pour la deuxième fois de ma vie (et donc simplement sauté des tâches complexes), donc 82% sur ce test correspondent au niveau programmeur non Java. Combien donc Java Junior, Java Programmeur et encore plus Java Senior devraient-ils recruter ?! Quel résultat pouvez-vous attendre de présent programmeur Java - 90, 95, 99 ? Et enfin, que se passe-t-il si le « programmeur » obtient un score inférieur à 82, mais postule néanmoins à un emploi ?!

Les tests ne sont pas toujours amusants et intéressants. Ce processus est généralement assez long et parfois plein de travail monotone. Il semble que récemment, les programmeurs ont utilisé la sortie standard ou un débogueur pour tester les classes Java.

Dans cet article, je décrirai la bibliothèque JUnit 4, qui simplifie et automatise considérablement le processus d'écriture de tests.

Pour démontrer les principales capacités du JUnit Framework, écrivons une classe primitive en Java et simulons-la. Cette classe aura deux méthodes : trouver la factorielle d'un nombre non négatif et la somme de deux nombres. De plus, l'instance de classe contiendra un compteur d'appels de méthode.

Classe publique MathFunc ( appels int; public int getCalls() ( appels de retour; ) public long factorial(int number) ( appels++; if (numéro 1) ( for (int i = 1; i

Écrivons maintenant les tests unitaires. Pour ce faire, nous allons créer une classe avec un certain nombre de méthodes de test. Naturellement, une classe peut également contenir des méthodes auxiliaires ordinaires. Pour que l'exécuteur du test puisse déterminer qui est qui, les méthodes de test doivent être annotées avec @Test.

Une annotation peut avoir les paramètres suivants :

• attendu - indiquez quelle exception sera générée par la méthode (voir exemple ci-dessous) ;
• timeout - après combien de temps, en millisecondes, le test cessera de s'exécuter et sera considéré comme un échec.

Si vous souhaitez indiquer qu'un certain test doit être ignoré, marquez-le avec l'annotation @Ignore. Bien que vous puissiez simplement supprimer l'annotation @Test.

Il peut arriver que vous ayez besoin d'un contexte, tel que des instances de classe pré-créées, pour exécuter chaque scénario de test. Et après exécution, vous devez libérer les ressources réservées. Dans ce cas, vous aurez besoin des annotations @Before et @After. La méthode marquée @Before sera exécutée avant chaque scénario de test et la méthode marquée @After sera exécutée après chaque scénario de test.

Si l'initialisation et la libération des ressources ne doivent être effectuées qu'une seule fois - respectivement, avant et après tous les tests - utilisez alors une paire d'annotations @BeforeClass et @AfterClass.

Et voici la classe de test elle-même avec plusieurs scripts de test :

Classe publique MathFuncTest ( mathFunc privé; @Avant public void init() ( math = new MathFunc(); ) @Après public void tearDown() ( math = null; ) @Test public void call() ( assertEquals(0, math .getCalls()); math.factorial(1); assertEquals(1, math.getCalls()); math.factorial(1); assertEquals(2, math.getCalls()); ) @Test public void factorial() ( assertTrue(math.factorial(0) == 1); assertTrue(math.factorial(1) == 1); assertTrue(math.factorial(5) == 120); ) @Test(expected = IllegalArgumentException.class) public void factorialNegative() ( math.factorial(-1); ) @Ignore @Test public void todo() ( assertTrue(math.plus(1, 1) == 3); ) )

La méthode des appels teste la validité du compteur d'appels. La méthode factorielle vérifie si la factorielle est calculée correctement pour certaines valeurs standards. La méthode factorialNegative vérifie qu'une IllegalArgumentException sera levée pour les valeurs factorielles négatives. La méthode todo sera ignorée. Essayez de supprimer l'annotation @Ignore lorsque vous expérimentez le code.

La méthode assertTrue vérifie si le résultat d'une expression est vrai. Quelques autres méthodes qui peuvent s'avérer utiles :

• assertEquals - le résultat attendu et le résultat reçu correspondent ;
• assertNull - le résultat de l'expression est nul ;
• assertNotNull - le résultat de l'expression est différent de null ;
• assertSame - les objets attendus et reçus sont le même objet.
• fail - la méthode génère une exception AssertionError - nous l'ajoutons là où l'exécution du programme ne doit pas aller.

Dans notre monde moderne Les IDE peuvent rechercher et exécuter simplement des tests dans un projet. Mais que se passe-t-il si vous souhaitez les exécuter manuellement à l'aide du code du programme. Pour ce faire, vous pouvez utiliser Runner. Il existe des versions texte - junit.textui.TestRunner, des versions graphiques - junit.swingui.TestRunner, junit.awtui.TestRunner.

Mais un peu plus méthode moderne est l'utilisation de la classe JUnitCore. Ajoutez la méthode principale suivante à la classe MathFuncTest :

Le public static void main (String args) lève une exception ( JUnitCore runner = new JUnitCore(); Result result = runner.run(MathFuncTest.class); System.out.println("run tests: " + result.getRunCount()); System.out.println("échec des tests : " + result.getFailureCount()); System.out.println("tests ignorés : " + result.getIgnoreCount()); System.out.println("succès : " + résultat .était un succès()); )

Et le résultat de l'exécution :

Exécuter les tests : 3 tests échoués : 0 tests ignorés : 1 succès : vrai

En plus versions précédentes Afin d'écrire une classe de test JUnit, il était nécessaire de créer un descendant de junit.framework.TestCase. Il a ensuite fallu définir un constructeur qui prend en paramètre une String - le nom de la méthode - et la transmettre à la classe parent. Chaque méthode de test devait commencer par le test du préfixe. Les méthodes setUp et TearDown ont été utilisées pour initialiser et libérer les ressources. Bref, l'horreur. Eh bien, maintenant tout est simple, oui.

C'est tout pour aujourd'hui. Je suis sûr que JUnit Framework vous aidera beaucoup. Les commentaires et questions sur l’article sont les bienvenus.