Probando Javascript que Manipula el DOM


He estado buscando en las suites de prueba de javascript y he encontrado QUnit para ser muy interesante. Entiendo cómo probar código computacional, pero...

¿Cómo se prueban las aplicaciones javascript escritas principalmente para la manipulación DOM?

Parece que probar la posición / color / etc de los elementos DOM sería un punto discutible porque terminarías haciendo algo como esto:

$("li.my_element").css("background-color", "#f00");

Y luego en su prueba...

$(function() {
    module("coloring");
    test("test_my_element", function() {
        var li_element_color = $("li.my_element").css('background-color');
        equals(li_element_color, "#f00");
    });
});

Esto simplemente no se siente bien porque básicamente solo hace esto:

var my_li= $("li.my_element");
my_li.css("background-color", "#f00");
if ( my_li.css("background-color") == "#f00" ) {
    return true;
}

¿Estoy loco? ¿Cómo se supone que se haga esto?

Editar : el corazón de la pregunta:

Supongo que lo que quiero decir es que necesito asegurarme de que el código no esté roto antes de implementar, pero la gran mayoría son ayudantes de interfaz de usuario y ajax. ¿Cómo pruebo que las cosas están apareciendo correctamente?

Algunos ejemplos:

  • prueba que aparece un diálogo de interfaz de usuario de jQuery encima de todos los demás elementos
  • prueba que el drag-n-drop funciona correctamente
  • prueba que el color de un droppable cambia cuando se deja caer un elemento sobre él
  • prueba que el ajax está funcionando correctamente
  • prueba que no hay comas extrañas que se rompan IE
Author: Jiaaro, 2009-09-16

5 answers

He encontrado que las pruebas Javascript/DOM, especialmente para las interacciones simples que está describiendo, no son tan útiles. Probarás que las cosas están configuradas correctamente, y como jQuery es tan declarativo, tus pruebas se parecen mucho a tu código.

Mi pensamiento actual es que si está escribiendo componentes JS más grandes, tiene sentido extraer un conjunto de comportamientos interrelacionados tanto en un complemento de jQuery como en un conjunto de pruebas para él.

Pero a partir de los ejemplos que mencionaste, parece que realmente estás buscando un nivel de protección dentro de tu sitio web integrado. Una herramienta como el Selenio probablemente será más potente y apropiada para ti. En particular,

  • se puede automatizar
  • puede ejecutarse contra múltiples navegadores, incluido IE
  • se ejecuta dentro del contexto de su aplicación web y páginas, por lo que drag-n-drop se puede probar donde realmente sucede en lugar de en algún entorno de prueba.
  • AJAX puede ser probado
 16
Author: ndp,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-09-19 03:58:47

En lugar de probar la función css de jQuery. Su prueba debe simular la función css, y asegurarse de que solo se llama una vez con el color correcto. El código probado debe ser suyo, no los frameworks.

 12
Author: Jason Harwig,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-09-17 14:00:18

Además de lo que Jason Harwig está diciendo, yo diría que las pruebas unitarias son una prueba para asegurarse de que el código se está ejecutando como se espera. Si quieres probar eso, entonces Jason tiene toda la razón sobre cómo deberías hacerlo. Si desea ejecutar pruebas para comprobar que la manipulación DOM está sucediendo (pruebas de interfaz de usuario) y no el código real que está haciendo la manipulación DOM (pruebas unitarias), entonces es posible que desee comprobar algo como Selenium, WatiN o Watir .

 3
Author: J.R. Garcia,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-09-17 14:09:47

Supongo que muchas personas prueban visualmente: es decir, miran la salida de su navegador en su monitor, para ver si parece como si el DOM hubiera sido manipulado como se esperaba.

Si eso necesita ser un caso de prueba automatizado (por ejemplo. para pruebas de regresión), luego tal vez graben la salida (como captura de pantalla) y hagan algo como comparar dos capturas de pantalla para ver si los resultados son los mismos.

En lugar de capturar una captura de pantalla, podría capturar todo el DOM, y hacer una comparación lado a lado de los árboles DOM capturados (que podría ser menos propenso a errores que la comparación de píxeles).

 1
Author: ChrisW,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-09-16 20:02:42

Pruebo AJAX cosas como esta:

  1. Hacer la llamada AJAX
  2. Configurar un temporizador JavaScript
  3. Compruebe el DOM para ver si se han producido los cambios esperados

Ahora bien, podría ser que la llamada AJAX no haya regresado antes de hacer su comprobación, pero esto también es información de prueba útil; con una llamada AJAX, hay (generalmente) algún tiempo después del cual lo llamaríamos un fallo. Como ejemplo, si estamos haciendo una sugerencia emergente, y se tarda 30 segundos para volver, que es un fallar.

 0
Author: Hogsmill,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-12-18 12:45:26