Avons-nous besoin de données de test ou pouvons-nous compter sur des tests unitaires et des tests manuels?

Nous travaillons actuellement sur un projet PHP / MySQL moyen / grand. Nous faisons des tests unitaires avec PHPUnit et QUnit et nous avons deux testeurs à temps plein qui testent manuellement l'application. Nos données de test (simulées) sont actuellement créées avec des scripts SQL.

Nous avons un problème avec la maintenance des scripts pour les données de test. La logique métier est assez complexe et un changement "simple" dans les données de test produit souvent plusieurs bogues dans l'application (qui ne sont pas de vrais bogues, juste le produit de données invalides). Cela est devenu un gros fardeau pour toute l'équipe car nous créons et modifions constamment des tables.

Je ne vois pas vraiment l'intérêt de maintenir les données de test dans les scripts car tout peut être ajouté manuellement dans l'application en environ 5 minutes avec l'interface utilisateur. Notre PM n'est pas d'accord et dit qu'avoir un projet que nous ne pouvons pas déployer avec des données de test est une mauvaise pratique.

Faut-il abandonner la maintenance des scripts avec des données de test et laisser les testeurs tester l'application sans données? Quelle est la meilleure pratique?

— Christian P
source

Réponses:

Vous mélangez deux concepts différents. L'une est la vérification , qui est basée sur les tests unitaires et les examens par les pairs. Cela peut être fait par les développeurs eux-mêmes, sans données de test et son objectif est de vérifier qu'un ensemble d'exigences est satisfait.

La seconde est la validation , et cela est fait par QA (vos testeurs). Pour cette étape, vous avez besoin de données de test car le testeur n'a pas besoin d'avoir une connaissance de la programmation dans l'application, seulement ses cas d'utilisation prévus. Son objectif est de valider que l'application se comporte comme prévu dans un environnement de production.

Les deux processus sont importants et nécessaires pour livrer un produit de qualité au client. Vous ne pouvez pas vous fier uniquement aux tests unitaires. Ce que vous devez comprendre est un moyen fiable de gérer vos données de test pour garantir leur validité.

EDIT: OK, je comprends ce que vous demandez. La réponse est oui, car le travail du testeur n'est pas de générer les données de test, juste de tester l'application. Vous devez créer vos scripts de manière à faciliter la maintenance et à garantir l'insertion de données valides. Sans les données de test, le testeur n'aura rien à tester. Cela dit, cependant, si vous avez accès à l'environnement de test , je ne vois pas pourquoi vous ne pouvez pas insérer les données de test manuellement plutôt qu'en utilisant des scripts.

— AJC
source

J'ai peut-être mal répondu à ma question en mentionnant les tests unitaires et les données de test. Je comprends que la validation n'est pas la même chose que les tests unitaires. Mon problème ici est que les données de test que nous créons avec les scripts peuvent être créées via l'interface utilisateur en 5 min. Pour insérer ces données dans l'application, vous n'avez pas besoin de connaître la programmation, il vous suffit de suivre les cas de test.

— Christian P

@ christian.p vérifier ma mise à jour concernant votre clarification de la question.

— AJC

Votre solution consiste donc à abandonner les scripts et à simplement ajouter des données de test manuellement via l'interface utilisateur? Qu'en est-il de la réponse fournie par P. Brian Brian Mackey et de ses réponses concernant le couplage des données avec l'interface utilisateur?

— Christian P

@ christian.p Eh bien, je suis d'accord pour que vous utilisiez des scripts. MAIS il n'y a aucune formalité ou règle qui dit que vous DEVEZ le faire. La principale raison d'utiliser des scripts pour générer des données factices est la vitesse (automatisation) et l'accès (à l'environnement de test). Si vous y avez accès et qu'il EST PLUS rapide et plus facile de le faire manuellement, il n'y a aucune raison que vous ne puissiez pas le faire. (MAIS garder un journal des données avec lesquelles vous avez testé).

— AJC

chaque testeur a son propre environnement de test et les testeurs suppriment complètement la base de données plusieurs fois par jour, il est donc impossible d'ajouter manuellement des données de test, mais nous pouvons leur demander poliment d'ajouter des données pour les tests.

— Christian P

Oui, avoir des tests unitaires et des maquettes de données est une meilleure pratique. Le chef de projet a raison. Puisqu'une modification «simple» des données de test produit souvent des bogues, c'est là le cœur du problème.

Le code doit être amélioré. Ne pas le faire (en disant que nous n'avons pas besoin de tests) n'est pas une solution, c'est simplement ajouter une dette technique . Décomposez le code en unités plus petites et plus testables, car il est impossible d'identifier les unités sans rupture.

Commencez à refactoriser. Gardez les améliorations petites afin qu'elles soient gérables. Recherchez les anti-modèles comme les classes / méthodes de Dieu, ne suivant pas SEC, la responsabilité unique, etc.

Enfin, regardez dans TDD pour voir si cela fonctionne pour l'équipe. TDD fonctionne bien pour s'assurer que tout votre code est testable (parce que vous écrivez d'abord les tests) et aussi pour rester maigre en écrivant juste assez de code pour passer les tests (minimiser l'ingénierie).

En général, si une série de processus de logique métier complexes produisent un ensemble de données, je considère cela comme un rapport. Encapsulez le rapport. Exécutez le rapport et utilisez l'objet résultant comme entrée pour le prochain test.

— P.Brian.Mackey
source

Je dois clarifier un peu les choses: "Un simple changement dans les données de test produit des bugs" - le problème ici n'est pas dans l'application - l'application fonctionne bien lorsque les données sont valides (et vous ne pouvez pas ajouter manuellement des données invalides) . Le problème ici est que des données de test non valides peuvent produire des erreurs lorsque vous essayez de travailler sur ces données. Nous devons donc également tester les données de test?

— Christian P

Ne vous laissez pas tromper sur une erreur de hareng rouge. Le fait que les données de test introduisent un bogue est un problème différent tous ensemble. Supprimer les tests n'est pas une solution, «gouverner le gouvernement» est tout autre chose également. Le problème est le code. Ce n'est pas testable parce que vous nous dites que vous ne pouvez pas écrire des tests qui ne cassent pas les choses. C'est pourquoi vous devez améliorer le code.

— P.Brian.Mackey

Vous avez peut-être mal compris ma question. Nous avons des tests unitaires qui fonctionnent et chaque nouvelle fonctionnalité que nous écrivons a des tests unitaires. Je ne suggère pas que nous supprimions les tests qui ne réussissent pas ou que nous n'écrivions pas du tout de tests. Je suggère simplement que nous n'utilisons pas les scripts pour créer des données factices dans la base de données parce que les testeurs manuels font la même chose.

— Christian P

"Je ne vois pas vraiment l'intérêt de maintenir les données de test dans les scripts" <- Supprimer le support de test est ce que je dis. Pas de suppression des anciens tests. C'est une mauvaise idée. Vous réduisez la reproductibilité et vous vous connectez à une interface utilisateur qui fait partie de la chose même que vous essayez de tester et de pouvoir vous adapter au changement. Découpez-vous de l'interface utilisateur. Gardez l'automatisation des données.

— P.Brian.Mackey

Mais comment pouvons-nous résoudre le problème des données factices non valides? Si nous continuons à créer des données fictives pour la base de données, comment vérifions-nous si les données fictives sont correctes ou non? Si la règle métier requiert cette valeur X = 2 et que la base de données accepte X = 100 - comment vérifier l'intégrité des données de test lorsque la règle métier est complexe?

— Christian P

Il s'agit d'un problème très courant et très difficile également. Les tests automatisés qui s'exécutent sur une base de données (même une base de données en mémoire, telle que HSQLDB ) sont généralement lents, non déterministes et, comme un échec de test indique uniquement qu'il y a un problème quelque part dans votre code ou dans vos données, ils sont pas beaucoup d'information.

D'après mon expérience, la meilleure stratégie consiste à se concentrer sur les tests unitaires pour la logique métier. Essayez de couvrir autant que possible votre code de domaine principal. Si vous obtenez cette partie correctement, ce qui est en soi un défi, vous obtiendrez la meilleure relation coût-avantage pour les tests automatisés. Quant à la couche de persistance, j'investis normalement beaucoup moins d'efforts sur les tests automatisés et je laisse le soin aux testeurs manuels dédiés.

Mais si vous voulez vraiment (ou avez besoin) d'automatiser les tests de persistance, je vous recommande de lire Growing Object-Oriented Software, Guided by Tests . Ce livre a un chapitre entier dédié aux tests de persistance.

— Otavio Macedo
source