2010-11-16 39 views
0

J'ai une méthode qui contient des objets de données, effectue des calculs pour remplir des champs précédemment vides sur les objets en fonction des autres champs, puis renvoie le résultats. Cette méthode ne franchit pas vraiment les frontières d'intégration - les objets de données sont des entités avec un arbre de dépendances assez complexe sur d'autres entités, mais du point de vue de cette méthode ce ne sont que des objets avec état (merci ORM).Test d'état et de comportement sur un code qui ne franchit pas les limites d'intégration

Il me semble que le test unitaire nécessiterait une vérification de l'état - mettre en place des données, exécuter le code pour faire les calculs et vérifier les résultats. Est-ce un argument légitime pour ignorer ce qui semble être un conseil général selon lequel les tests doivent vérifier le comportement, et non l'état? Ou suis-je en train de mal interpréter la littérature axée sur les tests?

Répondre

2

Je dirais que vous testez le comportement de la méthode qui fait les calculs, donc ce n'est pas un problème. Certaines personnes pourraient suggérer que le fait d'avoir le comportement dans une méthode séparée (en tant que service) et non sur les classes qui contiennent les données pourrait être une odeur de code, mais c'est un problème différent.

+0

Merci, cela me donne un peu de penser à – iftheshoefritz

+0

Malheureusement, je ne peux pas mettre la méthode sur les objets de données individuels que les calculs pour chaque instance impliquent les valeurs sur un groupe d'autres instances :) – iftheshoefritz

+0

Dans ce cas, vous est bon! –

0

Le comportement est que l'état d'entrée donné vous donne l'état de sortie attendu. Les tests unitaires doivent créer des objets fictifs (éventuellement des simulacres) avec un état connu, exécuter la méthode en cours de test et vérifier que la sortie (dans ce cas, c'est l'état du paramètre d'entrée) est correcte.