asp-classic watin mbunit automated-tests

asp classic - Pruebas automatizadas para ASP clásico



asp-classic watin (3)

El nuevo WatiN 2.0 beta 1 ofrece algunas clases base para ayudarlo a estructurar clases de prueba.

Básicamente se trata de tener una clase para cada página (heredando la clase WatiN.Core.Page). En estas clases de página, agrega propiedades para cada control al que desea acceder. Algo como:

public Button OkButton { get { return Document.Button("okbuttonId"); }

y puede crear métodos para envolver algunas acciones más complicadas en una página. Por ejemplo:

public void AddPerson(string name, string email) { /// logic goes here tp click on NewButton, set the textfields and click on OkButton }

Estas clases de página ofrecen la ventaja de definir tus elementos en un solo lugar.

En su código de prueba puede crear una clase de página de la siguiente manera:

using(var ie = new IE("www.somedomain.com/person")) { var page = ie.Page<PersonDetailPage>(); page.AddPerson("J. Doe", "[email protected]"); // Do some Assert }

Otra clase base interesante para ayudarlo a estructurar su código es la clase Control. Cuando use ASP, usará controles que no se procesarán en un solo elemento html en la página representada. En cambio, a menudo será una construcción de elementos contenidos en un elemento Div. Al crear su propia clase de control y heredar Control, podrá ajustar los controles (html) internos y el comportamiento. Esto hace que sea muy fácil reutilizar el control en sus clases de página. Siguiendo un ejemplo sobre cómo crear una instancia de un control:

var calendar = Document.Control<CalendarControl>("calendarId");

Espero que esto te dé una idea de cómo puedes estructurar tus páginas y controles.

Jeroen

¿Alguien hace pruebas de QA automatizadas para un sitio ASP clásico? Empecé a buscar en WatIn y MBUnit, pero no estoy seguro de la mejor manera de estructurar las pruebas.


Probé el sitio ASP con Watir . Si está buscando una manera de estructurar las pruebas, eche un vistazo al marco WatirCraft .


FWIW, hemos estado usando WatiN y MbUnit para las pruebas de integración web durante los últimos 3 años.

Hemos separado las pruebas en 3 proyectos:

  1. QA.Framework: contiene un código de pegamento para configurar accesorios de prueba y varias extensiones de MbUnit y WatiN personalizadas.

  2. QA.SiteMap: Contiene clases de Página y Control organizadas jerárquicamente en espacios de nombres que corresponden a diferentes dominios y partes de los sitios. Este proyecto sirve para desacoplar las pruebas de la mayor parte de la estructura del sitio web. Puedes pensarlo como un modelo de los sitios.

  3. QA.Tests: contiene las pruebas reales también organizadas jerárquicamente en espacios de nombres. Las pruebas aprovechan el Mapa del sitio y el Framework según sea necesario para interactuar con el sitio web. De esta forma, hay mucha menos duplicación de código que si cada prueba contuviera los mismos ID de botón una y otra vez ...

Jeff.