J'ai un très ancien projet mis en œuvre dans (classique) ASP et SQL Server 2000. En raison de préoccupations de qualité, j'ai envisagé la possibilité de mettre en œuvre une forme de test de qualité automatisé. Toutefois, les pages Web sont ASP Le projet est vraiment 85% de procédure SQL Server stockée, fonctions, vues et DTS. (Beaucoup de dépendance à la DTS) Beaucoup de génération de code se produit de SQL Server. P>
En ce qui concerne la DTS, nous espérons éventuellement Mettez à niveau la base de données sur SQL Server. 2005 - Donc, si le test unitaire ne peut pas être configuré sur DTS, qu'en est-il de la SSIS? p>
J'ai trouvé Aspunit mais il ne semble plus être maintenu ... p>
Quant à ma question, c'est vraiment une question de plusieurs parties. p>
Je suis vraiment dans une mauvaise situation avec ce projet; Toute conseille de contrôle de la qualité générale serait grandement appréciée ... em> p>
4 Réponses :
On dirait que vos problèmes sont réellement supérieurs à des tests unitaires. Je dirais que vos principaux problèmes seraient mieux résolus à un niveau de test d'intégration. P>
Étant donné que vos pages sont générées en grande partie par SQL, les tests Unités ASP ne couvrent qu'un faible pourcentage de problèmes. Vous aurez donc une meilleure couverture en testant les pages finales à l'aide d'un outil automatisé tel que watin ou ieunit / < / a>. p>
Vous pouvez penser à ceux-ci en termes de test de l'unité, mais ils testent vraiment le résultat final après l'intégration au lieu de tester les résultats de fonctions plus petites. Bien que vous puissiez manquer des changements de niveau inférieurs, vous contournez les problèmes de conception sous-jacents. P>
Tant que votre résultat final reste le même, votre test ne se souciera pas de si le contenu de la zone provenait de ASP ou SQL. P>
La question devient donc que WATIN fonctionne avec ASP classique? Je ne vois aucune indication pour dire que ça fait. Je vois que IEUnit est une bonne possibilité. Nous pourrions faire un bon pourcentage de tests avec ça ...
Avec le soutien de Leslie, je pense que c'est la réponse dont j'avais besoin. Encore merci.
Vous pourriez avoir un coup d'œil à Tests de l'unité Ajaxed . (La bibliothèque est toujours maintenue) p>
Pourrait être une solution possible en plus des autres aussi. Merci.
watin fonctionnera bien. Il manipule le navigateur, de sorte que cela ne se soucie pas de quelle langue le code est écrit ou si le code est bon ou mauvais, ou conçu pour la qualification ou non. C'est des tests de régression et non des tests unitaires. Mais c'est un excellent endroit pour commencer. p>
Vous pouvez utiliser votre outil de test de l'unité de choix: Nunit, Mbunit, Mstest, etc. P>
pour la mise à niveau SQL elle elle elle elle elle-même (et toute autre modification du code SQL), j'en examinerais l'unité SQL (ne l'utilisait pas) ou quelque chose de similaire pour mettre en œuvre des tests d'unité sur la base de données. P>
Vous pouvez le faire à côté des autres stratégies de test que vous sélectionnez. P>
Soyez conscient des inconvénients à tester via l'interface utilisateur: http://blog.Objectmentor.com/articles/2010/01/04/u-test-automation-Tools-are-snake-oil . Comprenez que les tests via UI sont généralement fragiles lorsque les concepteurs veulent apporter des modifications qui devraient être correctes pour eux. Pour une mise à niveau strictement versions SQL, cependant, vous devriez être bien. P>
Cet article que quelqu'un change la balise
ASP code> à
asp-classique code>, pour un autre message que quelqu'un a changé
asp-classique code> à
asp code> ASP code> . Je ne peux pas gagner. :-)