La réponse courte est non". La partie la plus intéressante est pourquoi / comment cette situation pourrait survenir.
Je pense que la confusion survient parce que vous essayez de vous conformer à des pratiques de test strictes (tests unitaires par rapport à des tests d'intégration, moquages, etc.) pour un code qui ne semble pas adhérer à des pratiques strictes.
Cela ne veut pas dire que le code est "faux", ou que des pratiques particulières sont meilleures que d'autres. Simplement que certaines des hypothèses formulées par les pratiques de test peuvent ne pas s'appliquer dans cette situation, et il peut être utile d'utiliser un niveau similaire de "rigueur" dans les pratiques de codage et les pratiques de test; ou du moins, reconnaître qu'ils peuvent être déséquilibrés, ce qui rendra certains aspects inapplicables ou redondants.
La raison la plus évidente est que votre fonction effectue deux tâches différentes:
- En levant les yeux en
Person
fonction de leur nom. Cela nécessite des tests d’intégration, pour s’assurer qu’il peut trouverPerson
objets qui sont supposés être créés / stockés ailleurs.
- Calculer si un
Person
est assez âgé, en fonction de son sexe. Cela nécessite des tests unitaires pour s'assurer que le calcul fonctionne comme prévu.
En regroupant ces tâches dans un bloc de code, vous ne pouvez en exécuter aucune sans l'autre. Lorsque vous souhaitez effectuer des tests unitaires, vous êtes obligé de rechercher un Person
fichier (depuis une base de données réelle ou depuis un talon ou une maquette). Lorsque vous souhaitez vérifier que la recherche s'intègre au reste du système, vous devez également effectuer un calcul sur l'âge. Que devrions-nous faire avec ce calcul? Devons-nous l'ignorer ou le vérifier? Cela semble être la situation exacte que vous décrivez dans votre question.
Si nous imaginons une alternative, nous pourrions avoir le calcul seul:
def is_old_enough?(person)
if person.male?
return person.age > 21
else
return person.age > 18
end
end
S'agissant d'un calcul pur, nous n'avons pas besoin d'effectuer de test d'intégration.
Nous pourrions également être tentés d'écrire la tâche de recherche séparément:
def person_from_name(name = 'filip')
return Person::API.new(name)
end
Cependant, dans ce cas, la fonctionnalité est si proche de Person::API.new
celle que je dirais que vous devriez plutôt l'utiliser (si le nom par défaut est nécessaire, serait-il préférable de le stocker ailleurs, comme un attribut de classe?).
Lorsque vous écrivez des tests d'intégration pour Person::API.new
(ou person_from_name
), tout ce dont vous avez besoin est de savoir si vous récupérez les résultats attendus Person
; tous les calculs basés sur l'âge sont pris en charge ailleurs, de sorte que vos tests d'intégration peuvent les ignorer.