Comment tester les règles métier?

Question

J'ai besoin d'un test unitaire pour m'assurer d'accumuler correctement les heures de vacances. Toutefois, les heures de vacances s’accumulent conformément à une règle de gestion. Si la règle change, le test unitaire est interrompu.

Est-ce acceptable? Devrais-je exposer la règle par une méthode, puis appeler cette méthode à partir de mon code et de mon test pour vérifier que le test unitaire n'est pas si fragile?

Ma question est la suivante: quelle est la bonne façon de tester les règles métier susceptibles de changer?

Answer 1

Vos tests doivent garantir que le code obéit correctement à la règle de gestion. Par conséquent, je n'écrirais pas de tests qui contourneraient la règle métier ou s'appuieraient sur le code de règle métier lui-même. Au lieu de cela, lorsque la règle de gestion change, je modifie d'abord le test pour refléter la nouvelle règle de gestion, puis lorsque mon code ne réussit plus le test, allez le réparer afin qu'il passe le test.

Ce que vous ne voulez pas, c’est d’écrire votre test afin que, lorsque vous modifiez l’application de la même règle de gestion, votre test soit rompu. C'est plus facile à dire qu'à faire, mais ce que vous voulez tester est essentiellement le minimum requis pour implémenter la règle sans dicter de manière trop étroite la manière dont le code est implémenté. Si le résultat de la règle est différent, modifiez d'abord le test, puis le code correspondant.

Vous ne souhaitez pas non plus que le test soit associé à des données spécifiques. Supposons que, lors du calcul d’une taxe, votre test ne soit pas écrit pour supposer que la classe sous test utilise 5% de la taxe. Au lieu de cela, vous devez rédiger votre test afin qu'il fournisse le pourcentage de taxe, puis vérifier que le calcul est effectué correctement. Vraisemblablement, vous aurez une plage de valeurs à tester pour vous assurer que les valeurs hors plage sont également capturées. Cela se traduira par une meilleure conception, car cela vous aidera à éviter les valeurs codées en dur et à rendre votre code de production plus flexible pour les modifications de données.

Answer 2

J'ai une configuration similaire. Toutefois, mes règles d’entreprise sont compilées mais comportent des options configurables (les vôtres peuvent être différentes). Lorsqu'une règle de gestion modifie un mode de fonctionnement fondamental, mon unité teste les tests. C'est en fait prévu - et bon! Cela signifie que je peux isoler toutes les ondulations inattendues de mon système et mettre à jour les tests en fonction des modifications.

Si vos règles sont externes (une sorte de langage de script ou un sproc de base de données), vous devrez les envelopper dans un test d'intégration et relier vos tests d'intégration pour une exécution automatisée. Bien qu'ils ne soient plus des tests unitaires, les tests d'intégration sont également assez importants et vous aideront, de la même manière que les tests unitaires, à éviter des ondulations inattendues dues à un changement de règle de gestion.

Answer 3

On dirait que vous avez des règles commerciales, puis que vous avez des clients de ces règles. Si ces deux peuvent varier indépendamment, il serait sage de concevoir votre API en conséquence.

Tel qu’il a été présenté, votre question semble pouvoir être résolue avec l’utilisation appropriée du motif Stratégie. La stratégie représente vos règles de gestion, vous pouvez donc les tester à l'unité dans un contexte pur sans vous soucier du client.

Lorsque la règle de gestion change, il peut être plus logique de laisser l'ancienne stratégie telle quelle (au cas où vous en auriez besoin ultérieurement) et d'écrire (et de tester l'unité) une stratégie entièrement nouvelle qui représente la nouvelle règle de gestion. .

Lorsque vous avez complètement terminé la nouvelle stratégie, vous pouvez remplacer la stratégie dans le client.

Lorsque l’unité teste le client, vous devez le faire par rapport à une stratégie de test double (comme un simulacre ou un talon) pour vérifier que le client interagit correctement avec la stratégie sans dépendre d’une implémentation particulière de la stratégie.

De cette manière, vous obtenez une séparation nette des problèmes et vous garantissez la maintenance de vos tests unitaires. Vous respectez également le principe d'ouverture / fermeture.

Answer 4

Il semble correct que le test échoue si les règles sont modifiées - c'est à prévoir.

Vous pouvez faciliter la maintenance du test à l'avenir si vous utilisez un gabarit de données au lieu de valeurs codées en dur dans le test lui-même. Par exemple, si votre méthode doit retourner foo, vous pouvez l'avoir dans le fixture. Lorsque vous modifiez la logique métier, vous modifiez simplement le montage et vous n'avez pas à passer par le test unitaire lui-même.

Bien sûr, cela dépend fortement du type de logique que vous testez et peut ne pas toujours être applicable.

Answer 5

Je pense que c'est une question incorrecte La règle de gestion et le test unitaire sont dans différents niveaux d'abstraction. La règle de gestion se situe au plus haut niveau d'abstraction (Business Modeling), mais le test unitaire sert à tester une unité de code dont le niveau d'abstraction est le plus bas. vous ne pouvez donc pas utiliser le test unitaire pour valider ou vérifier une entreprise. règle. En outre, une règle commerciale après analyse et conception peut affecter plusieurs unités de codes. Par conséquent, vous ne pouvez pas utiliser de test d'unité pour valider ou vérifier une règle commerciale . Je pense que vous pouvez utiliser un scénario de test ou un scénario BDD pour valider et vérifier une règle de gestion.