J'ai une classe de surveillance de fichiers très simple qui vérifie toutes les 2 secondes si un fichier a changé et, le cas échéant, la méthode Code: Test: Onchange est appelée.
Y a-t-il un moyen facile de vérifier si la méthode Onchange est appelée dans un test d'unité?
3 Réponses :
avec Mockito , vous pouvez vérifier si une méthode est appelée au moins une fois / jamais.
Voir point 4 dans Cette page
par exemple:
Vous pouvez utiliser n'importe quel cadre moqueur et non seulement moqueur. Jetez un coup d'œil à EasyMock ou jmock et choisissez ce que vous aimez. La règle de test des tests d'unité d'écriture est que vous ne devez que vousignez que les objets que vous pouvez contrôler. En d'autres termes, les objets simulés doivent être mis à la disposition de la classe sous test à l'aide d'arguments de constructeur / de setters ou de paramètres sur votre méthode sous test. Par cette logique, vous ne pouvez pas vous moquer des invocations statiques, des objectifs finaux ou privés ou «nouveaux» créés dans la méthode de la classe sous test.
Avez-vous une idée de la façon dont vous pouvez le faire dans EasyMock? Je trouve la documentation qui manque à cela. Quand je crée une mock pour la propriétéfileWatcher comme ceci: PropertyFileWatcher PropertyFileWatcher = CreatemockBuilder (ProtitierFileWatcher.class) .withconstructor (fichier) .CreateTemock (); et enregistrer l'appel attendu à Onchange et Replay: PropertyFileWatcher.onchange (fichier); REPLAY (PropertyFileWatcher); La méthode Onchnage est appelée immédiatement et les informations sont imprimées à Sysout, mais je voudrais juste vérifier si cette méthode a été appelée ou non
N'utilisez pas de mokito de pouvoir faire la solution atomicboolean.
Le deuxième lien n'est pas à jour. Vous pouvez voir cette page: Documentation Mockito
La plupart de ces liens sont cassés. Veuillez paraphraser / citer le contenu directement dans la réponse pour éviter la redondance.
Il suffit de vous faire savoir que le lien est cassé.
Si je comprends bien, votre PropertyFileWatcher est censé être sous-classé. Alors, pourquoi ne pas sous-classer cela comme ceci:
Voici une simple modification de votre test.
@Test
public void testPropertyFileWatcher() throws Exception {
final File file = new File("testfile");
file.createNewFile();
final AtomicBoolean hasCalled = new AtomicBoolean( );
PropertyFileWatcher propertyFileWatcher =
new PropertyFileWatcher(file)
{
protected void onChange ( final File localFile )
{
hasCalled.set( true );
assertEquals( file, localFile );
}
}
Timer timer = new Timer();
timer.schedule(propertyFileWatcher, 2000);
FileWriter fw = new FileWriter(file);
fw.write("blah");
fw.close();
Thread.sleep(8000);
// check if propertyFileWatcher.onChange was called
assertTrue( hasCalled.get() );
file.delete();
}
J'aime vraiment cette solution car elle n'ajoute pas une dépendance à un cadre moqueur; Cependant, des cadres moqueurs sont une nécessité pour les tests unitaires; C'est pourquoi j'accepte la suggestion moqueuse en tant que réponse acceptée à ma question.
@ nkr1pt. Allez certainement avec un cadre de moqueur de bonne réputation. Si vous n'êtes pas confiné à la version 1.4 de JDK, jetez un coup d'œil à jmock.