Comment traiter avec de longs tests unitaires de fonctionnement?

https://stackoverflow.com/questions/368622

21-08-2019
|

Question

J'ai environ 100 tests unitaires et avec une couverture de 20%, que je suis en train d'augmenter la couverture et aussi c'est un projet en développement afin d'ajouter de nouveaux tests garder.

Actuellement en cours d'exécution mes tests après chaque construction est impossible qu'ils prend environ 2 minutes.

test comprend:

Lire un fichier à partir des dossiers de test (style axé sur les données pour simuler des choses HTTP)
Faire des requêtes HTTP réels local serveur web (ce qui est une douleur énorme à se moquer, je ne vais pas)
Pas tous les tests unitaires, mais il y a aussi assez compliquées des classes multithread qui doivent être testées et je fais tester le comportement global du test. Ce qui peut être considéré comme les tests fonctionnels, mais ils doivent être exécuté à chaque fois ainsi.

La plupart des fonctionnalités de lecture nécessite HTTP, etc. TCP faire je ne peux pas les changer parce que c'est l'idée du projet si je change ces tests, il sera inutile de tester des choses.

Aussi je ne pense pas avoir les outils les plus rapides pour exécuter des tests unitaires. Ma configuration actuelle utilise VS TS avec Gallio et nUnit comme cadre. Je pense que VS TS + Gallio est un peu plus lent que d'autres.

Que voulez-vous me recommander pour résoudre ce problème? Je veux exécuter des tests unitaires après chaque peu change btu actuellement ce problème interrompt mon flux.

D'autres précisions Edit:

Le code est très couplé! Malheureusement, et le changement est comme un énorme processus de refatoring. Et il y a un syndrome d'œufs de poules là où j'ai besoin des tests unitaires pour factoriser un tel code, mais je ne peux pas avoir plus de tests unitaires si je ne le refactoriser:)

Code couplé hautement ne me permet pas de diviser les tests en petits morceaux. Aussi je ne testons pas des choses privées, il est un choix personnel, ce qui me permettra de développer beaucoup plus vite et le gain encore une grande quantité de prestations.

Et je peux confirmer que tous les tests unitaires (avec une bonne isolation) assez rapide en fait, et je n'ai pas un problème de performance avec eux.

D'autres précisions:

Et je peux confirmer que tous les tests unitaires (avec une bonne isolation) assez rapide en fait, et je n'ai pas un problème de performance avec eux.

La solution

Ces derniers ne sonnent pas comme des tests unitaires pour moi, mais plus comme des tests fonctionnels. C'est très bien, l'automatisation des tests fonctionnels est bon, mais il est assez commun pour les tests fonctionnels soient lents. Ils testent le système (ou de gros morceaux de celui-ci).

Les tests unitaires ont tendance à être rapide parce qu'ils testent une chose isolée de tout le reste. Si vous ne pouvez pas tester des choses dans l'isolement de tout le reste, vous devriez considérer qu'un signe d'avertissement que vous code est trop étroitement couplé .

Pouvez-vous dire quels tests vous qui sont des tests unitaires (test 1 chose seulement) par rapport à des tests fonctionnels (test de 2 ou plusieurs choses en même temps)? Lesquelles sont rapides et ceux qui sont lents?

Autres conseils

Vous pouvez diviser vos tests en deux groupes, l'un pour les tests courts et un pour les tests de longue durée, et exécutez les tests de longue durée moins fréquemment lors de l'exécution des tests courts après chaque changement. En dehors de cela, se moquant des réponses des autres demandes serveur Web et votre application marques aboutiraient à un test plus court terme.

Je recommande une approche combinée à votre problème:

exécuter fréquemment un sous-ensemble des tests qui miment le code que vous apportez des modifications à (par exemple des tests du même paquet, module ou similaire). Moins fréquemment des tests qui sont plus exécuter retirés du code que vous travaillez actuellement.
Divisez votre suite dans au moins deux: une course rapide et des tests de fonctionnement lents. Exécutez les tests de fonctionnement rapide plus souvent.
Envisager d'avoir une partie des moins susceptibles d'échouer essais doivent être exécutés uniquement par un serveur d'intégration continue automatisée.
Apprendre des techniques pour améliorer les performances de vos tests. Plus important encore en remplaçant l'accès aux ressources du système lent par fakes plus rapides. Par exemple, l'utilisation dans la mémoire des flux plutôt que des fichiers. Stub / railler l'accès http. etc.
Apprenez à utiliser des techniques de rupture dépendance à faible risque, comme ceux qui sont énumérés dans le (très fortement recommandé) livre « Travailler efficacement avec Legacy Code ». Ceux-ci vous permettent de faire efficacement votre code plus testable sans appliquer refactorisations à haut risque (souvent en faisant temporairement la conception réelle pire, comme casser l'encapsulation, jusqu'à ce que vous pouvez factoriser à une meilleure conception avec le filet de sécurité des tests).

L'une des choses les plus importantes que j'ai appris du livre mentionné ci-dessus: il n'y a pas de magie, en collaboration avec le code existant la douleur, et toujours sera douleur. Tout ce que vous pouvez faire est d'accepter ce fait, et faire de votre mieux pour travailler lentement votre chemin hors du désordre.

D'abord, ce ne sont pas des tests unitaires.

Il n'y a pas grand-chose d'un point en cours d'exécution des tests fonctionnels comme ça après chaque petit changement. Après un changement considérable que vous voulez exécuter vos tests fonctionnels.

Deuxièmement, ne pas avoir peur de se moquer de la partie Http de l'application. Si vous voulez vraiment tester l'unité de l'application est un MUST. Si vous n'êtes pas disposé à le faire, vous allez perdre beaucoup plus de temps à essayer de tester votre logique actuelle, en attendant les requêtes HTTP de revenir et d'essayer de mettre en place les données.

Je garderais vos tests de niveau d'intégration, mais elle cherche à créer des tests unitaires réels. Cela permettra de résoudre vos problèmes de vitesse. les tests unitaires réels ne sont pas d'interaction DB ou interaction HTTP.

J'utilise toujours une catégorie pour « LongTest ». Les tests sont exécutés tous les soirs et non pendant la journée. De cette façon, vous pouvez réduire votre temps d'attente par beaucoup. Essayez:. Votre catégorie test unitaire

On dirait que vous pourriez avoir besoin de gérer les attentes entre l'équipe de développement ainsi.

Je suppose que les gens sont en train de faire plusieurs construit par jour et sont epxected pour exécuter des tests après chaque construction. Vous pourriez nous être bien servis pour changer votre programme de test pour exécuter une construction avec des tests pendant le déjeuner, puis une autre pendant la nuit.

Je suis d'accord avec Brad que ces sons comme des tests fonctionnels. Si vous pouvez tirer le code à part ce serait génial, mais jusque-là je voudrais passer à des tests moins fréquents.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow