Antes de comenzar a desarrollar algo útil en Node.js, ¿cuál es su proceso? ¿Creas pruebas en VowJS, Expresso? ¿Usas pruebas de Selenio? ¿Cuando?flujo de trabajo de programación Node.js - Pruebas, Código, Pruebas
Estoy interesado en obtener un buen flujo de trabajo para desarrollar todas mis aplicaciones node.js similares a Rails (Cucumber, Rspec, Code).
Disculpe la cantidad de preguntas.
Déjame saber cómo te sale.
Mi metodología de prueba no está funcionando como en Java/Junit y realmente debería trabajar más en esto (mejorar). Realmente debería practicar TDD más.
Jugué un poco con expresso y me gustó el hecho de que podría generar informes de cobertura de código. Lo que pensé que faltaba era algo así como @before@beforeclass@after que puedes encontrar en java.
También jugué un poco con nodeunit que tiene configuración/desmontaje. Todavía me gusta jugar un poco más con este marco.
No me gusta la sintaxis de vowjs, pero es un framework BDD muy popular, así que tal vez debería usarlo (más) para venderme como muchos otros usuarios. Pero por ahora voy a descartar vowjs.
También jugué con zombie.js un poquito, que también es genial. También he visto recientemente otro marco de prueba genial que no recuerdo el nombre, pero afortunadamente hay suficientes opciones para hacer pruebas en node.js.
Lo único que no me gusta es que la integración con IDE no está a la altura en mi opinión. El IDE que tuve para Java no se puede comparar con lo que he encontrado para node.js, pero creo que con un poco de esfuerzo puedo crear un entorno de programación más útil. Trataré de mantenerlos informados sobre este progreso.
P.S: Pero lo que más me gusta es el administrador de paquetes npm. Cuando lo comparas con por ejemplo Maven solo dices wow. Todavía tengo algunos errores menores porque todavía es un proyecto joven. ¡Pero aún así, la npm es muy buena en mi opinión!
Lo primero que hago es escribir algo de documentación o hacer algunos wireframes. Ayuda a visualizar lo que quiero implementar.
Luego codigo la interfaz/esqueleto de mi módulo/aplicación, sin implementaciones.
Luego agrego especificaciones y pruebas usando testosterone (aunque los votos y el expresso son opciones más populares) y los paso por su implementación.
Si encuentra que se debe probar un método privado (se trata de E/S, tiene una lógica compleja ...) muévalo a otra clase y pruébelo de forma independiente.
Combina tus llamadas de E/S tanto como puedas. Las pruebas se ejecutarán más rápido y no tendrá que lidiar con los efectos secundarios. Recomiendo gently.