Quelle est la meilleure pratique pour tester les règles de beols avec JUnit?
Jusqu'à présent, nous avons utilisé JUNIT avec DBUnit pour tester des règles. Nous avons eu des échantillons de données qui ont été mis à HSQLDB. Nous avons eu quelques forfaits de règles et à la fin du projet, il est très difficile de faire une bonne contribution de test pour tester certaines règles et ne pas tirer d'autres.
La question exacte est donc que comment puis-je limiter les tests dans Junit à une ou plusieurs règles de test?
5 Réponses :
N'essayez pas de limiter l'exécution de la règle à une seule règle pour un test. Contrairement aux classes OO, les règles simples ne sont pas indépendantes des autres règles. Il n'a donc pas de sens de tester une règle isolée de la même manière que vous testeriez une seule classe à l'aide d'un test d'unité. En d'autres termes, tester une seule règle, testez le bon effet en association avec les autres règles.
Au lieu de cela, exécutez des tests avec une petite quantité de données sur toutes vos règles, c'est-à-dire avec un nombre minimal de faits dans la session de règle, et testez les résultats et peut-être qu'une règle particulière a été licenciée. Le résultat n'est pas réellement si différent de ce que vous avez à l'esprit, car un ensemble minimal de données de test peut uniquement activer une ou deux règles.
Quant aux données d'échantillonnage, je préfère utiliser des données statiques et définir des données de test minimales pour chaque test. Il existe différentes façons de le faire, mais la création de manière programmatique d'objets de fait en Java pourrait être suffisamment bonne.
Oui, je sais comment fonctionne l'exécution de règles. C'est la façon dont nous le faisons maintenant. Mon problème est avec cette approche qu'il est très difficile de faire des données de test suffisantes et appropriées. Parce que nous ne limitons pas les règles annulables, aucune autre règle peut exécuter et modifier le résultat final. Il est donc difficile de prédire le résultat final des affirmations. C'était la raison pour laquelle je pensais qu'il serait préférable de tester les règles izolées.
Je suppose que j'essayais de dire que "toute autre règle peut exécuter et changer le résultat final" est exactement pourquoi tester une règle d'isolement est moins significative.
Un test unitaire avec DBUnit ne fonctionne vraiment pas. Un test d'intégration avec DBUnit fait. Voici pourquoi: - Un test unitaire doit être rapide. - Une base de données DBUnit restauration est lente. Prend 30 secondes facilement. - Une application dans le monde réel a beaucoup de colonnes non nulles. Ainsi, les données, isolées pour une seule fonction, utilise encore facilement la moitié des tables de la base de données. - Un test unitaire doit être isolé. - Restauration de la base de données de DBUnit pour chaque test pour les garder isolé présente des inconvénients: --- Exécution de tous les tests prend des heures (d'autant plus que l'application se développe), afin que personne ne se exécute eux, ils cassent en permanence, de sorte qu'ils sont désactivés, donc il n'y a pas de test, de sorte que vous application est plein de bugs. --- Création d'une demi-base de données pour chaque test unitaire est beaucoup de travail de création, beaucoup de travaux d'entretien, peut facilement devenir invalide (en ce qui concerne la validation qui de schéma base de données ne prennent pas en charge, voir Hibernate Validator) et fait ussually une mauvaise emploi de représenter la réalité.
Au lieu de cela, écrire des tests d'intégration avec DbUnit: - Un DbUnit, le même pour tous les tests. Chargez une seule fois (même si vous exécutez 500 tests). - Enveloppez chaque test dans une transaction et rollback la base de données après chaque test. La plupart des méthodes utilisent la propagation de toute façon nécessaire. Situé à seulement la sale testdata (pour le réinitialiser dans le test suivant s'il y a un prochain test) que lorsque la propagation est REQUIRES_NEW. - Remplir cette base de données avec des cas d'angle. Ne pas ajouter les cas les plus communes que sont strictement nécessaires pour tester vos règles métier, donc Ussually seulement 2 cas communs (pour être en mesure de tester « un à plusieurs »). - Rédiger des tests à l'épreuve: - Ne pas tester le nombre de règles activées ou le nombre de faits insérés. - Au lieu de cela, tester si un certain fait inséré est présent dans le résultat. Filtrer le résultat sur un certain ensemble de propriétés pour X (différente de la valeur courante de cette propriété) et de tester le nombre de faits insérés avec ce jeu de propriétés à X.
Personnellement, j'utilise des tests unitaires pour tester des règles isolées. Je ne pense pas qu'il y ait quelque chose de trop tort avec cela, tant que vous ne comprenez pas un faux sentiment de sécurité que votre base de connaissances fonctionne car les règles isolées fonctionnent. Tester toute la base de connaissances est plus important.
Vous pouvez écrire les tests d'isolation avec AgendAfilter et apatrideSession code source: http://blog.athico.com/2007/07/my-rules-dont-work-as-expète- What-CAN.HTML
J'ai créé une bibliothèque simple qui aide à rédiger des tests d'unité pour les baveries. L'une des caractéristiques est exactement ce dont vous avez besoin: Déclarez des fichiers DRL particuliers que vous souhaitez utiliser pour votre test de l'unité: Pour plus de détails, consultez le blog Post:
L'URL GitHub n'est pas trouvée et manque d'artefact PL.Maciejwalkowiak: Junit-beols: JAR: 1.0 à Maven!
Le projet @youseFalkahky a été archivé, vous pouvez le chercher à github.com/maciejwalkowiak/junit-drools
Le test unitaire consiste à prendre au minimum la pièce de code et à tester toutes les utilisations possibles définissant des spécifications. Avec des tests d'intégration, votre objectif n'est pas toutes possibles d'usecases, mais l'intégration de plusieurs unités qui travaillent ensemble. Faire de même avec les règles. Séparer les règles par signification et but de l'entreprise. "Unité la plus simple sous le test" pourrait être un fichier avec un seul ou Une haute cohension ensemble de règles et ce qui est requis pour qu'il fonctionne (le cas échéant), comme un fichier de définition de DSL commun et une table de décision. Pour un test d'intégration, vous pouvez prendre un sous-ensemble significatif ou toutes les règles du système.
Avec cette approche, vous aurez de nombreux tests d'unité isolés et peu de tests d'intégration avec une quantité limitée de données d'entrée communes pour reproduire et tester des scénarios communs. L'ajout de nouvelles règles n'aura aucune incidence sur la plupart des tests d'unités, mais peu de tests d'intégration et refléteront la manière dont les nouvelles règles ont une incidence sur le flux de données commun.
Considérez Junit Library de test qui pourrait convenir à cette approche
On dirait une bonne réponse, mais cela ne fonctionne pas dans les boursnes 7.5 parce que (comme le Maven Repo le met): kie.internal - l'API interne des bourses et JBPM qui n'est pas compatible avec les versions. :-(