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?

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.

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.

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.