Desarrollo de interfaz de usuario en JavaScript utilizando principios de TDD

StackOverflow https://stackoverflow.com/questions/96086

  •  01-07-2019
  •  | 
  •  

Pregunta

He tenido muchos problemas al intentar encontrar la mejor manera de seguir correctamente los principios de TDD mientras desarrollaba la interfaz de usuario en JavaScript.¿Cuál es la mejor manera de hacer esto?

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

¿Fue útil?

Solución

He hecho algo de TDD con Javascript en el pasado y lo que tenía que hacer era hacer la distinción entre pruebas unitarias y de integración.Selenium probará su sitio en general, con la salida del servidor, sus publicaciones, 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 interactuará y su secuencia de comandos.La herramienta que utilizarás para esto es básicamente Unidad Js, 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 es incluir el HTML bloqueado en la página con tus funciones.Desde allí, puede probar la interacción de su secuencia de comandos con los componentes de la interfaz de usuario en la unidad aislada del HTML simulado, su secuencia de comandos y sus pruebas.

Esto puede resultar un poco confuso, así que veamos si podemos hacer una pequeña prueba.Supongamos que un TDD supone que después de cargar un componente, una lista de elementos se colorea según el contenido del LI.

pruebas.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 varios 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 pueda ver el problema aquí: debe mantener su HTML simulado aquí en la página sincronizado con la estructura de los controles de su servidor.Pero te ofrece un buen sistema para TDD con JavaScript.

Otros consejos

Nunca he realizado TDD con éxito en el código UI.De hecho, lo más cerca que estuvimos fue separar el código de la interfaz de usuario 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 pueden ser TDD sin muchos problemas y sin complicarse demasiado.

En mi experiencia, la vista siempre se dejó para nuestras pruebas de aceptación de usuarios (escribimos aplicaciones web y nuestros UAT usaron HttpUnit de Java).Sin embargo, en este nivel es realmente una prueba de integración, sin la propiedad de prueba aislada que deseamos con TDD.Debido a esta configuración, primero tuvimos que escribir nuestro código/pruebas de controlador/modelo, luego la interfaz de usuario y la UAT correspondiente.Sin embargo, en el código GUI de Swing que he estado escribiendo últimamente, primero he estado escribiendo el código GUI con códigos auxiliares 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 darte es lo que ya pareces sospechar: separa tu código UI de tu lógica tanto como sea posible y TDD.

he encontrado el MVP La arquitectura es muy adecuada para escribir UI comprobables.Su Presentador y Modelo las clases pueden simplemente ser probadas al 100% por unidad.Sólo tienes que preocuparte por el Vista (que debería ser una capa delgada y tonta que envía eventos al presentador) para pruebas de interfaz de usuario (con Selenium, etc.)

Tenga en cuenta que en este caso estoy hablando de usar MVP completamente en el contexto de la interfaz de usuario, sin necesariamente cruzar al lado del servidor.Su interfaz de usuario puede tener su propio presentador y modelo que reside completamente en el lado del cliente.El presentador impulsa la interacción/validación de la interfaz de usuario, etc.lógica mientras que el modelo mantiene información de estado y proporciona un portal al backend (donde puede tener un modelo separado).

También deberías echarle un vistazo a Presentador primero Técnica TDD.

Esta es la razón principal por la que cambié al Google Web Toolkit...Desarrollo y pruebo 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 la implementación.

Los conjuntos de pruebas funcionales y de integración verifican que el código resultante funcione como se esperaba después de implementarlo en un servidor de prueba.

Estoy a punto de empezar a utilizar Javascript TDD en un nuevo proyecto en el que estoy trabajando.Mi plan actual es usar qunitar 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 garantizar que las pruebas se ejecuten en todos los navegadores), usaré Selenio para cargar automáticamente el arnés de prueba en cada navegador y leer el resultado.Estas pruebas se ejecutarán en cada registro del control de fuente.

yo también voy a usar JSCoverage para obtener un análisis de cobertura de código de las pruebas.Esto también se automatizará con Selenium.

Actualmente estoy en medio de la configuración de esto.Actualizaré esta respuesta con detalles más exactos una vez que haya resuelto la configuración.

Herramientas de prueba:

Lo que hago es pinchar al Dom para ver si obtengo lo que espero.Un gran efecto secundario de esto es que al hacer que tus pruebas sean rápidas, también haces que tu aplicación sea rápida.

Acabo de publicar un conjunto de herramientas de código abierto que ayudará enormemente con JavaScript tdd.Es una composición de muchas herramientas de código abierto que le brinda una aplicación principal requirejs funcional lista para usar.

Proporciona comandos únicos para ejecutar:servidor web de desarrollo, ejecutor de pruebas de navegador único jasmine, ejecutor de pruebas de navegador múltiple jasmine js-test-driver y concatenización/minificación para JavaScript y CSS.También genera una versión no minificada de su aplicación para la depuración de producción, precompila sus plantillas de manillar y admite la internacionalización.

No se requiere configuración.Simplemente funciona.

http://github.com/davidjnelson/agilejs

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top