Desarrollar la interfaz de usuario en JavaScript utilizando los principios de TDD

He tenido muchos problemas para tratar de encontrar la mejor manera de seguir correctamente los principios de TDD mientras desarrollo la interfaz de usuario en JavaScript. ¿Cuál es la mejor manera de hacerlo?

¿Es mejor separar lo visual de lo funcional? ¿Desarrolla primero los elementos visuales y luego escribe pruebas y luego codifica la funcionalidad?

0
agregado editado
Puntos de vista: 2

7 Respuestas

0
agregado

He encontrado que la arquitectura MVP es muy adecuada para escribir interfaces de usuario comprobables. Sus clases Presentador y Modelo pueden simplemente probarse al 100%. Solo tiene que preocuparse por la vista </​​strong> (que debería ser una capa delgada y tonta que solo dispara eventos al presentador) para la prueba de UI (con Selenium, etc.)

Tenga en cuenta que en el estoy hablando de usar MVP por completo 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 consultar la técnica de TDD Presenter First .

0
agregado

Lo que hago es empujar al 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á mucho 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 navegador único jasmine, corredor de prueba de navegador multiuso 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.

http://github.com/davidjnelson/agilejs

0
agregado

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 realizar las pruebas unitarias. Mientras se desarrollan las pruebas, se pueden ejecutar simplemente actualizando la página de prueba en un navegador.

Para una integración continua (y asegurar que las pruebas se ejecuten en todos los navegadores), usaré Selenium para cargar automáticamente la prueba arnés en cada navegador, y lea 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:

0
agregado

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 funcional verifican que el código resultante esté funcionando como se esperaba después de implementarlo en un servidor de prueba.

0
agregado

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, la vista siempre quedaba para nuestras pruebas de aceptación del usuario (escribimos aplicaciones web y nuestras UAT usaban 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.

Entonces, para reiterar, el único consejo que puedo dar es lo que parece sospechar: separe el código de UI de su lógica tanto como sea posible y TDD.

0
agregado

He hecho algo de 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 los 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>
    
  • red
  • green
   
</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 varios pasos, por lo que para nuestro control, necesitaremos varios ejemplos.

yourcontrol.js (paso1)

function ColorCtrl( id ) {
 /* Fail! */    
}

yourcontrol.js (paso2)

function ColorCtrl( id ) {
    $$("#mockList li").forEach(function(item, index) {
        item.setStyle("backgrond-color", item.getText());
    });
    /* Success! */
}

Probablemente puedas ver el punto de dolor aquí, tienes que mantener tu HTML falso aquí en la página sincronizado con la estructura de los controles de tu servidor. Pero te ofrece un buen sistema para TDD con JavaScript.

0
agregado