debugging - ¿Hay una manera de ingresar al código CasperJS y depurar paso a paso
remote-debugging (1)
Aunque he estado utilizando CasperJS durante algún tiempo, y confío en el registro de la consola para la depuración. Me preguntaba si existe algún IDE que sea compatible con la depuración paso a paso de CasperJS o si hay otra forma (depuración remota) de ingresar al código de CasperJS. ¿Alguien lo ha hecho con éxito? Cualquier información será útil.
Gracias,
Cuando quiero depurar con CasperJS, hago lo siguiente: Ejecuto mi script con slimerJS (abre una ventana de Firefox para que pueda ver fácilmente el problema de clics, los problemas de llenado de formularios ajax, error de retorno, carga de medios ... y En qué paso se bloquea el código).
Con eso, no necesito a menudo mirar la consola y no llamo this.capture (''img.jpg'') varias veces para depurar (por ahora no pruebo el diseño sensible, por lo que no necesito usar captura, eche un vistazo a PhantomCSS si lo prueba).
Utilizo slimerJS para depurar (siempre con casper), pero phantomJS en Integración continua (jenkins) (sin cabeza), aunque también puede usar slimerjs (sin cabeza) con xvfb en Linux o Mac.
Pero a veces tengo que mirar la consola para obtener más detalles, así que uso estas opciones (también puedes llamarlas desde la línea de comandos):
casper.options.verbose = true;
casper.options.logLevel ="debug";
El nombre de sus cierres será útil con estas opciones, porque se mostrará el nombre.
No creo que exista un IDE: si un paso falla, la pila con todos los pasos siguientes se detiene de todos modos (bueno, todavía es posible hacer una ''especie de pirateo'' usando espera múltiple y encapsularlos) para realizar diferentes cierres y obtenga el resultado de todos ellos, incluso si uno de ellos falla, pero en este caso no estamos apilando pasos síncronos, sino ejecutando instrucciones asíncronas: tenga cuidado con el tiempo de espera y el flujo lógico si lo intenta). Atención: dije ''si un paso falla'', si es solo una instrucción en un cierre que falla, por supuesto que se ejecutarán los siguientes pasos.
Así que un cierre que falla -> se ejecutan los siguientes pasos. Un paso que falla (ex: thenOpen (fssfsf) con fssfsf no definido), la pila se detendrá. La espera múltiple () se puede hacer de forma asíncrona.
Entonces, si tiene muchos errores y ejecuta sus pruebas secuencialmente (pasos de apilamiento), solo puede depurarlos uno por uno, o por cierre para funciones de pasos independientes. Creo que un IDE podría funcionar en este caso- (-> para uno archivo. Las pilas son, por supuesto, independientes si inicia una carpeta). Y, por lo general, al principio, inicia su archivo cada vez que termina un paso. Y cuando estás acostumbrado a la herramienta, escribes todo el script a la vez.
En la mayoría de los casos, los errores se deben a problemas asíncronos, de alcance, de contexto (en realidad son problemas de js, aunque Casper simplifica los problemas asíncronos: "El tema de devolución de llamada / escucha es una implementación del patrón Promise."):
Si desea completar un conjunto de instrucciones, no olvide el IIFE o use el casper en cada función, y abarque todo con una instrucción then () (o directamente cada una). Puedo mostrar algunos ejemplos si es necesario. De lo contrario, repetirá el último índice ''i.length'' veces, no hay alcance de bucle en js, por defecto i tiene la misma referencia.
Cuando haga clic en un enlace al final de un paso, use una función de esperar () también: siguiente instrucción; en lugar de un then (). Si he entendido bien la instrucción then (), se inicia cuando se completa el paso anterior. Así que se lanza justo después del click (). Si este clic inicia una devolución de ajax, y su siguiente paso raspa o prueba el resultado de esta devolución de ajax, fallará al azar, porque no ha pedido explícitamente que espere el recurso. Vi algunos problemas así en mis primeras pruebas.
No mezcle los dos contextos: entorno de casper y entorno de página DOM. Utilice la función de evaluación () para pasar de uno a otro. En la función de evaluación, puede pasar un argumento del contexto de Casper a la página DOM ...
...Como eso :
var casperContext = "phantom";
casper.evaluate(function(pageDomContext) {
console.log("will echo ->phantom<- in the page DOM environment : " + pageDomContext + ", use casper.on(''remote.message'') to see it in the console");
}, casperContext);
O puede verlo directamente en el navegador con slimerJS usando alert () en lugar de console.log ().
Utilice setFiltrer para manejar el cuadro de confirmación y solicitud.
Si su sitio web también existe en la versión móvil, puede manipular el agente de usuario para sus pruebas móviles.
Puede llamar a los módulos de nodo en un archivo casperJS, en archivos usando el módulo de prueba también. Bueno, no es del todo cierto, vea usar el módulo de nodo de Casper . Algunas funciones de los nodos centrales se implementan en modo fantasma (y también más delgado), como fs, proceso secundario, pero no siempre están bien documentados. Prefiero ejecutar mis pruebas con nodo así. El nodo es útil para iniciar sus pruebas en paralelo (proceso hijo). Le sugiero que ejecute tantos procesos como tenga núcleo. Bueno, depende de su tipo de script, con un escenario normal (abra una página y verifique algunos elementos) Puedo ejecutar 10 procesos secundarios en paralelo sin fallo aleatorio (computadora local), pero con algunos elementos que se cargan lentamente (como multi svg, a veces xml ...), use require (''os''). cpus (). length o un script como ese: Repita un paso X veces . De lo contrario, tendrá un error aleatorio, incluso si aumenta el tiempo de espera. Cuando se bloquea, no puedes hacer nada más que
reload()la página.
Luego puede integrar sus pruebas en jenkins usando el comando xunit. Solo especifique los diferentes índices para cada archivo log.xml, jenkins (XUnit -> JUnit) los administrará: patrón * .xml.
Sé que realmente no respondí a tu pregunta, pero creo que para depurar, enumerar los principales problemas específicos sigue siendo la mejor manera.
Todavía hay funciones útiles para depurar:
var fs = require(''fs'');
fs.write("results.html", this.getPageContent(), ''w'');
Prefiero esta manera en lugar de this.debugHTML (). Puedo verificar en mi archivo results.html si faltan etiquetas (en relación con el navegador que usa Firebug u otra herramienta). O a veces, si necesito marcar solo una etiqueta, el resultado en la consola no es un problema, así que: this.getHTML ("my selector"); y aún puede canalizar el resultado del registro: casperjs test test.js > test.html
- Otro truco: si ejecuta sus pruebas en local, a veces el tiempo de espera predeterminado no es suficiente (congelación de la red) (5 s).
Entonces -> 10sec:
casper.options.waitTimeout = 10000;
Algunas diferencias entre Phantom y Slimer:
Con más delgado, si establece casper.options.pageSettings.loadImages = false; y en su archivo intenta raspar o probar el peso / altura ... de un elemento, funcionará con más delgado pero no con fantasma. Así que configúralo en verdadero en el archivo específico para mantener la compatibilidad.
Debe especificar una ruta absoluta con más delgado (con incluir, importar-> medios de entrada, ...).
Ejemplo:
this.page.uploadFile(''input[name="media"]'', fs.absolute(require(''system'').args[4]).split(fs.separator).slice(0, -1).join(fs.separator) + ''/../../../../avatar.jpg'');
Para incluir un archivo de la carpeta raíz (trabajar en cada subdir / OS, mejor que en la inclusión anterior), también puede hacerlo con un nodo, como si se requiriera () -:
phantom.injectJs(fs.workingDirectory + ''/../../../../global.js'');