He tenido muchos problemas para encontrar la mejor manera de seguir correctamente los principios TDD mientras desarrollo la IU en JavaScript. ¿Cuál es la mejor manera de hacerlo?Desarrollo de la IU en JavaScript utilizando los principios TDD
¿Es mejor separar lo visual de lo funcional? ¿Desarrolla primero los elementos visuales y luego escribe pruebas y luego codifica la funcionalidad?
he hecho algunas TDD con Javascript en el pasado, y lo que tenía que hacer era hacer la distinción entre las pruebas de Unidad e Integración.Selenium pondrá a prueba su sitio en general, con la salida del servidor, sus publicaciones posteriores, llamadas ajax, todo eso. Pero para las pruebas unitarias, nada de eso es importante.
Lo que desea es solo la interfaz de usuario con la que va a interactuar y su secuencia de comandos. La herramienta que usará para esto es básicamente JsUnit, que toma un documento HTML, con algunas funciones de Javascript en la página y las ejecuta en el contexto de la página. Entonces, lo que harás será incluir el código HTML aplastado en la página con tus funciones. A partir de ahí, puede probar la interacción de su secuencia de comandos con los componentes de la interfaz de usuario en la unidad aislada del HTML burlado, su secuencia de comandos y sus pruebas.
Eso puede ser un poco confuso, así que veamos si podemos hacer una pequeña prueba. Permite a algunos TDD suponer que después de cargar un componente, se colorea una lista de elementos en función del contenido del LI.
tests.html
<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
<ul id="mockList">
<li>red</li>
<li>green</li>
</ul>
</body>
<script>
function testListColor() {
assertNotEqual($$("#mockList li")[0].getStyle("background-color", "red"));
var colorInst = new ColorCtrl("mockList");
assertEqual($$("#mockList li")[0].getStyle("background-color", "red"));
}
</script>
</html>
Obviamente TDD es un proceso de múltiples pasos, por lo que para nuestro control, necesitaremos varios ejemplos.
yourcontrol.js (paso 1)
function ColorCtrl(id) {
/* Fail! */
}
yourcontrol.js (paso 2)
function ColorCtrl(id) {
$$("#mockList li").forEach(function(item, index) {
item.setStyle("backgrond-color", item.getText());
});
/* Success! */
}
probablemente puede ver el punto de dolor aquí, usted tiene que mantener su maqueta HTML aquí en la página en sincronización con la estructura de lo que controlará tu servidor. Pero te ofrece un buen sistema para TDD con JavaScript.
Esta es la razón principal por la que cambié al Google Web Toolkit ... Desarrollé y probé en Java y tengo una expectativa razonable de que el JavaScript compilado funcionará correctamente en una variedad de navegadores. Dado que TDD es principalmente una función de prueba unitaria, la mayor parte del proyecto se puede desarrollar y probar antes de la compilación y el despliegue.
Las suites de prueba de integración y funcionalidad verifican que el código resultante esté funcionando como se esperaba después de implementarlo en un servidor de prueba.
Nunca he con éxito TDD código de UI. Lo más cerca que llegamos fue separar el código UI tanto como fuera posible de la lógica de la aplicación. Esta es una de las razones por las que el patrón modelo-vista-controlador es útil: el modelo y el controlador se pueden TDD sin muchos problemas y sin complicarse demasiado.
En mi experiencia, siempre quedaba la vista para nuestras pruebas de aceptación del usuario (escribimos aplicaciones web y nuestras UAT usaban la HttpUnit de Java). Sin embargo, en este nivel es realmente una prueba de integración, sin la propiedad de prueba en aislamiento que deseamos con TDD. Debido a esta configuración, primero tuvimos que escribir nuestro controlador/prueba de modelo/código, luego la UI y el UAT correspondiente. Sin embargo, en el código de la GUI de Swing que he estado escribiendo últimamente, he estado escribiendo primero el código GUI con stubs para explorar mi diseño de la interfaz, antes de agregarlo al controlador/modelo/API. YMMV aquí sin embargo.
Por lo tanto, para reiterar, el único consejo que puedo dar es lo que ya parece sospechar: separe el código de UI de su lógica tanto como sea posible y TDD.
Estoy a punto de comenzar a hacer Javascript TDD en un nuevo proyecto en el que estoy trabajando. Mi plan actual es usar qunit para hacer las pruebas unitarias. Mientras se desarrollan las pruebas, se pueden ejecutar simplemente actualizando la página de prueba en un navegador.
Para la integración continua (y para garantizar que las pruebas se ejecutan en todos los navegadores), usaré Selenium para cargar automáticamente el arnés de prueba en cada navegador y leer el resultado. Estas pruebas se ejecutarán en cada checkin para controlar la fuente.
También voy a utilizar JSCoverage para obtener un análisis de cobertura de código de las pruebas. Esto también se automatizará con Selenium.
Actualmente estoy en el medio de configurar esto. Actualizaré esta respuesta con detalles más exactos una vez que tenga configurada la configuración.
herramientas de prueba:
Consulte también: JavaScript unit test tools for TDD
que he encontrado la arquitectura MVP a ser muy adecuado para escribir comprobable interfaces de usuario. Su Presentador y Las clases del modelo pueden simplemente probarse al 100%. Usted sólo tiene que preocuparse por el Ver (que debe ser una capa mudo, delgada única que desencadena eventos al presentador) para las pruebas de interfaz de usuario (con selenio, etc.)
Tenga en cuenta que en el que estoy hablando acerca del uso de MVP completamente en el contexto de la interfaz de usuario, sin necesariamente cruzar al lado del servidor. Su UI puede tener su propio Presentador y Modelo que vive completamente del lado del cliente. El presentador dirige la lógica de interacción/validación de la interfaz de usuario, etc., mientras que el modelo conserva la información de estado y proporciona un portal al servidor (donde puede tener un modelo separado).
También debe echar un vistazo a la técnica de TDD Presenter First.
Lo que hago es presionar el Dom para ver si obtengo lo que espero. Un gran efecto secundario de esto es que al hacer las pruebas rápidamente, también hace que su aplicación sea rápida.
Acabo de lanzar un kit de herramientas de código abierto que ayudará muchísimo con JavaScript tdd. Es una composición de muchas herramientas de código abierto que le proporciona una aplicación de red troncal requireks de manera inmediata.
Proporciona comandos únicos para ejecutar: servidor web dev, corredor de prueba de un solo navegador jasmine, corredor de prueba de varios exploradores jasmine js-test-driver y concatenación/minificación para JavaScript y CSS.También genera una versión no modificada de su aplicación para la depuración de producción, precompila sus plantillas de manubrio y admite la internacionalización.
No se requiere configuración. Simplemente funciona.