Comment puis-je tester un site de formulaires Web?

Comment puis-je tester un site de formulaires Web? Il me semble que cela dépend en grande partie de l'état et de la contribution de l'utilisateur, ce ne serait pas faisable.

Si ce n'est pas possible, existe-t-il une alternative automatisée valide?

Oui, vous pouvez. Vous devez juste faire attention à bien séparer vos préoccupations. En bref, vous devez supprimer toute votre logique du code-behind et la mettre dans d'autres classes.

Il existe deux façons courantes de procéder.

Le moyen le plus simple est de repenser tous vos gestionnaires d'événements en termes de "Quelles informations le système me donne-t-il? De quelles informations ai-je besoin pour remplir la page?" puis fournir une classe de service qui effectue cette conversion.

Dans ce cas, la couche de service doit en savoir très peu sur la nature de votre couche de présentation. Vous devez toujours prendre les données renvoyées par le service et remplir les composants corrects du WebForm dans votre code-behind et cela reste non testé (au moins par des tests unitaires, vous pouvez toujours utiliser des tests d'intégration). Mais c'est rarement là où le code va mal, il est beaucoup plus susceptible d'échouer dans la logique.

Une manière plus compliquée mais plus efficace consiste à utiliser le modèle Model View Presenter . Lorsque nous avons essayé cela, nous avons constaté que les Presenters étaient rapidement devenus très couplés au framework et, plus nous développions MVP, plus il était clair que MVP voulait vraiment être MVC mais ne pouvait pas l'être.

Cela dit, d'autres l'ont fait avec beaucoup de succès - il y a même un framework webformsmvp disponible pour supprimer les charges lourdes - donc votre kilométrage peut varier.

De toute évidence, une page entière de formulaires Web n'est pas une unité et ne peut donc pas être testée à l'unité. Cependant, vous pouvez faire certaines choses pour les tests automatisés:

• test unitaire des composants individuels de la page (toutes les méthodes qui exécutent la logique réelle)
• composants de test unitaire utilisés par la page (contrôles personnalisés, logique métier sous-jacente, etc.)
• test de fonctionnalité automatisé (en contrôlant à distance un navigateur ou en envoyant des requêtes HTTP via quelque chose comme cURL)
• tests de pénétration automatisés (il existe des outils qui tenteront de trouver des points d'injection possibles et exécuteront automatiquement des attaques par injection inoffensives mais détectables sur votre page)
• test de charge
• vérifier la mise en page par rapport à une liste de puces de convivialité et de style maison (bien que cela soit très difficile à automatiser; il est généralement plus possible de le faire manuellement de temps en temps)

Je suis désolé d'avoir raté la partie "unité" de la question ...

SeleniumHQ est votre ami pour les tests du front-end. Ce n'est pas un test unitaire, plutôt un test de boîte noire. Vous devez toujours penser à des cas de test valides ...

Parlant d'expérience: seulement si c'est bien fait. Par «droit», j'entends un code-back minimal et quelque chose comme le Model-View-Presenter susmentionné pour rendre le formulaire Web «stupide». Cela s'avère généralement très difficile avec les applications de friches industrielles, car elles n'ont pas été conçues dans cet esprit et c'est un effort presque herculéen de refactoriser / réécrire des pages pour l'utiliser.

watin

Je trouve que les tests unitaires Web sont extrêmement utiles, même si c'est juste pour donner une idée générale d'un bug de régression ou pour de nouveaux projets.

En ce qui concerne l'état, vous créez vos tests unitaires comme vous le feriez avec des tests non-UI - ils effacent la base de données au début du test et reconstruisent la base de données pour ne contenir que l'état de démarrage. Chaque test unitaire encapsule ensuite une seule page, ou généralement une tâche distincte sur une page.

http://watin.org/ est un autre outil de test Web mais pour C # /. NET. Vous écrivez les tests sous forme de tests unitaires:

[Test] 
public void SearchForWatiNOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).TypeText("WatiN");
    browser.Button(Find.ByName("btnG")).Click();

    Assert.IsTrue(browser.ContainsText("WatiN"));
  }
}

Il est actuellement basé sur IE mais a un support expérimental pour Firefox et Chrome. Vous pouvez à peu près automatiser tout ce que vous feriez dans les tests manuels, y compris l'interaction Javascript.

Vous ne pouvez pas vraiment tester de manière unitaire un site Web, simplement parce que les demandes Web se produisent sur un câble (ou via une pile TCP). Ainsi, les tests ne correspondent pas à la définition de "test unitaire", ils seraient, vraisemblablement, des tests de bout en bout.

Pour ces types de tests, vous pouvez utiliser une suite comme Selenium qui exécute un navigateur Web dans les coulisses. Un mot d'avertissement cependant: généralement ce type de test est très difficile et imprévisible, car il y a beaucoup de pièces mobiles!

Plus intéressant cependant, cela m'inquiète un peu pourquoi vous auriez besoin de tester des formulaires Web. N'insérez-vous pas trop de logique dans le code et avez-vous une logique commerciale anémique par hasard?

Jasmin

Au cours des 5 dernières années, Jasmine est devenu un outil clé pour les tests unitaires frontaux. Il est souvent intégré dans les tests de construction automatiques avec Node et npm

Par https://en.wikipedia.org/wiki/Jasmine_(JavaScript_testing_framework) :

Jasmine est un framework de test open source pour JavaScript. [2] Il vise à fonctionner sur n'importe quelle plate-forme compatible JavaScript, à ne pas empiéter sur l'application ni sur l'IDE, et à avoir une syntaxe facile à lire. Il est fortement influencé par d'autres cadres de tests unitaires, tels que ScrewUnit, JSSpec, JSpec et RSpec. [3]

Malgré toutes les mentions de javascript, il peut également être utilisé pour les tests unitaires d'un formulaire Web simple.

ASP.NET

Lors du développement d'un site ASP.NET, nous avons pu exécuter des tests unitaires sur:

• Le domaine
• Contrôleurs / présentateurs BL
• le code derrière les pages Web Forms

Il est possible de TDD tout cela, selon votre architecture. La seule chose que vous ne pouvez pas tester est la disposition du fichier de balisage.