Dans un projet où il existe des exigences non fonctionnelles qui spécifient le temps d'exécution maximal pour une action spécifique, l'AQ doit vérifier les performances de cette action sur une machine dédiée en utilisant du matériel précis sous une charge précise, le matériel et la charge étant spécifiés dans les exigences.
D'un autre côté, certaines modifications erronées du code source peuvent gravement affecter les performances. Noter cet impact négatif tôt , avant que le code source n'atteigne le contrôle de source et soit vérifié par le département QA, pourrait être bénéfique en termes de temps perdu par le département QA signalant le problème, et par le développeur le corrigeant plusieurs validations plus tard.
Pour ce faire, est-ce une bonne idée:
Utiliser des tests unitaires pour avoir une idée du temps passé à exécuter la même action² n fois,
Pour utiliser le délai d'expiration par test via l'
[TestMethod, Timeout(200)]
attribut en C #?
J'attends plusieurs problèmes avec cette approche:
Conceptuellement , les tests unitaires ne sont pas vraiment pour ça: ils sont censés tester une petite partie d'un code, rien de plus: ni la vérification d'une exigence fonctionnelle, ni un test d'intégration, ni un test de performance.
Le délai d'expiration des tests unitaires dans Visual Studio mesure-t-il vraiment ce qui devrait être mesuré, en tenant compte du fait que l'initialisation et le nettoyage sont inexistants pour ces tests ou sont trop courts pour affecter les résultats?
Mesurer les performances de cette façon est moche. Exécuter un benchmark sur n'importe quelle machine¹ indépendamment du matériel, de la charge, etc., c'est comme faire un benchmark qui montre qu'un produit de base de données est toujours plus rapide qu'un autre. D'un autre côté, je ne m'attends pas à ce que ces tests unitaires soient un résultat définitif, ni quelque chose qui est utilisé par le département QA . Ces tests unitaires seront utilisés uniquement pour donner une idée générale des performances attendues et essentiellement pour alerter le développeur que sa dernière modification a cassé quelque chose, affectant gravement les performances .
Le développement piloté par les tests (TDD) est impossible pour ces tests. Comment échouerait-il, en premier lieu, avant de commencer à implémenter du code?
Trop de tests de performances affecteront le temps requis pour exécuter les tests, donc cette approche est limitée aux actions courtes uniquement.
Compte tenu de ces problèmes, je trouve toujours intéressant d'utiliser de tels tests unitaires s'ils sont combinés avec les mesures de performances réelles par le service QA.
Ai-je tort? Y a-t-il d'autres problèmes qui rendent totalement inacceptable l'utilisation de tests unitaires pour cela?
Si je me trompe, quelle est la bonne façon d'alerter le développeur qu'un changement de code source a gravement affecté les performances, avant que le code source n'atteigne le contrôle de code source et soit vérifié par le service d'assurance qualité?
¹ En fait, les tests unitaires ne devraient s'exécuter que sur des PC de développeur ayant des performances matérielles comparables, ce qui réduit l'écart entre les machines les plus rapides qui ne pourront jamais échouer au test de performances et les machines les plus lentes qui ne réussiront jamais à le réussir.
² Par action, je veux dire un morceau de code assez court qui passe quelques millisecondes à s'exécuter.