Pourquoi devrais-je faire UnitTest pour mes SQL, DAL et BLL si mon application n'appelle que des metodes BLL?

Question

J'ai mis quelques tests à l'aide VisualStudio environnement de test intégré, ils simultate ce que mon application Web ferait en appelant des méthodes BLL (ils seuls la couche d'interface utilisateur doit connaître et d'interagir avec) ...

Alors si leur comportement est correct - je fais passer mes tests - pourquoi j'écris des tests pour les couches inférieures telles que DAL/Stored Procedures autant de littérature que je suggère de faire?

Merci à tous, Peter.

Answer 1

Le test de bout en bout est bon et vérifie que votre application fonctionne dans certains cas. Miske Hevery a mis un bon billet de blog sur le test categorization où il fractionne le test unitaire, le test d'intégration et le test de bout en bout.

Unit-Testing Le test unitaire vérifie que la logique de cette méthode fonctionne correctement et que la gestion des erreurs est correctement effectuée. Ces tests devraient idéalement fonctionner en millisecondes et non en secondes. Si une fonction doit interagir avec quelque chose, comme le DAL, vous devez vous moquer de cette interface de la couche DAL, car une véritable interaction prendrait beaucoup de temps à s'exécuter. Ceux-ci offrent le meilleur retour sur investissement

Test d'intégration Ce niveau de test vérifie que l'interaction entre les couches logiques d'entreprise font exactement ce qu'ils devraient faire. C'est là que votre test d'unité interagirait avec une interface, comme le DAL, et vérifiez que le 'câblage' est correct. Il devrait y avoir un peu d'entre eux, mais pas trop que cela aurait un impact sur votre temps de construction

End-to-End Test Ils sont bons car ils vérifient que tout se tient de l'interface utilisateur tout le chemin jusqu'à la DAL. Ceux-ci testent beaucoup plus le 'câblage' et vérifient que ce que votre utilisateur peut faire ne va pas tuer votre application. Ceux-ci peuvent également inclure votre FitNesse et Web Tests, comme Selenium, passent.Le test unitaire offre le meilleur retour sur investissement et capture des bogues beaucoup plus coûteux que les autres zones, mais il est bon d'avoir un bon mélange du lot.

Answer 2

Parlant d'un fond NUnit

Test de l'accès SPs/données est pas aussi facile à faire. Vous devez vous assurer d'avoir une base de données "propre" chaque fois que vos tests sont exécutés, avec les données attendues au début pour garantir que vous obtiendrez les résultats escomptés. Vous devez donc soit restaurer une base de données à partir d'une sauvegarde propre à chaque fois, soit vous assurer que vos tests configurent la base de données avec les données dont elle a besoin avant le démarrage des tests. Les tests unitaires devraient idéalement tourner aussi vite que possible, et c'est l'une des raisons pour lesquelles le DAL est souvent raillé lors des tests unitaires - pour supprimer le processus coûteux d'interaction avec la base de données. La chose à laquelle vous devez faire attention, c'est que si vous écrivez des «tests unitaires» pour SP/DAL, l'impact sur le temps d'exécution du test pourrait exploser, ce qui peut conduire les gens à ne pas faire les tests trop longtemps. Dans un environnement/environnement de construction à intégration continue, plus les tests sont longs à exécuter, plus il est long de préparer une build. Mon opinion personnelle est que j'aime utiliser une combinaison d'accès db moqueurs et réels dans mes tests unitaires, car j'aime savoir que mon code fonctionnera comme prévu tout le long de et vers le db, pour attraper des erreurs idiotes comme les SP manquantes/erreurs (en bordure entre les tests unité/intégration/fonctionnalité). Mais là où ce n'est pas si important, j'utilise des simulacres.