Para Node, no piense en Express Específico. Sin embargo, creo que lo que estás pidiendo cuando lo dijiste de esa manera es que probablemente te referías al desarrollo JD TDD externo para una aplicación web. ¿Es más lo que creo que quieres decir? ¿O estás probando conducir un servicio web? Sería útil comprender su caso de uso y qué tipo de “cosa” está creando. (por cierto, si estás creando un servicio web, te recomiendo Koa.js diseñado por el equipo que creó Express. Me encantó; te hará la vida mucho más fácil crear API)
Y depende del nivel de prueba que intente hacer (de afuera hacia adentro desde la interfaz de usuario hasta el backend o simplemente backend)
Este es probablemente uno de los mejores, por James Shore: Let’s Code: Test-Driven JavaScript
- ¿Cómo deberían las cuentas de administrador en un sitio web diferir de las cuentas de usuario?
- ¿Cuánto tiempo tardaré en saber si tengo un don para el desarrollo o la programación de sitios web? Tengo cero experiencia y deseo como mínimo aprender HTML, CSS y Javascript.
- ¿Qué opinas sobre el creador de plantillas de WordPress TemplateToaster.com?
- ¿Cuál es un ejemplo de entrevista telefónica para un puesto en HTML / CSS, JavaScript y jQuery?
- ¿Es una buena idea aprender Vim y programación al mismo tiempo, para poder acostumbrarme a codificar en Vim?
Pero todavía no hay una tonelada de recursos en torno al buen JS TDD. Poco a poco está mejorando, pero por ahora, publicaciones de blog dispersas en él o videos muy pequeños de personas que crean pruebas JS aquí y allá.
También busque Videos de Katas hechos en línea en JS que podrían ser fuentes adicionales de cómo TDD con JS.
JS es genial, pero dado que no está escrito, hay algunos desafíos que debes resolver, como familiarizarte con los patrones de nodos y, especialmente, con TDD y un buen diseño, si quieres hacer una inyección de dependencia en JS, no es tan fácil fácil ya que no hay buenas maneras de verificar que el tipo que entra en un método o módulo coincida con una interfaz esperada. Hay verificadores de tipos por ahí y uno nuevo que me gusta de Facebook llamado Flow en lugar del de Microsoft (mecanografiado que para mí está un poco hinchado). Flow realiza la verificación de tipos mediante inferencia durante el tiempo de ejecución, lo que hará que su código sea mucho más elegante y no tendrá que crear todos esos archivos, ya que el mecanografiado lo obliga a crear.
Entonces, sepa que con Node, habrá un par de cosas que resolver de inmediato (lo cual, por cierto, requiere mucha práctica para lograrlo, por lo que no necesita pensar tanto, todavía lo estoy practicando :)) :
- Diferentes patrones en cómo puede crear módulos / exponer en su aplicación a medida que diseña componentes en su código de nodo
- Cómo incorporar la inyección de dependencia limpiamente no solo para un buen diseño SÓLIDO sino también para que pueda inyectar cosas de sus pruebas en los módulos
Probablemente sería bueno para alguien crear algunos Katas Node.js. Lo haría, pero no tengo tiempo para inventarlos ahora 🙂 :. Creo que hacer Katas y probar diferentes patrones de Node Module sería muy útil en términos de obtener patrones s comunes en Node.js.
Interfaz
Intento no usar marcos simulados a menos que sea absolutamente necesario o si es demasiado difícil crear objetos simulados en JS, entonces podría considerar usar algo como Sinon.js, pero solo depende de cuán hinchado y detallado sea consumir un marco determinado. .
Por ejemplo, hay una biblioteca llamada Jest for React. No lo usé porque pude crear pruebas simples simplemente usando herramientas simples como React Test Utils combinadas con JSDom combinado con un par de otros middleware que pueden terminar en pruebas más flexibles y desacopladas en lugar de usar un marco como JEST que impone ciertas restricciones o “su manera” de probar siempre cosas. Solo digo que no siempre vaya inmediatamente e instale un Framework, busque formas alternativas de hacer lo mismo que un framework podría hacer con menos código y módulos más simples que puede usar en combinación para lograr el mismo resultado.
Una gran cantidad de marcos DI se interponen cuando todo lo que necesita es una interfaz simple definida en sus módulos JS y simplemente burlarse de esas dependencias en sus pruebas mediante una simple inyección de lenguaje natural, no siempre necesita un marco DI y Siempre trato de esquivarlos si puedo.
Dado que no hay muchos buenos ejemplos, la gente tiende a recurrir a Sinon.js, Jest, etc. de inmediato. Tenga cuidado, mire a su alrededor más sobre otras formas de prueba, es todo lo que digo. Hay publicaciones de blog que salen cada vez más sobre cómo hacer eso. Por ejemplo, aquí hay un buen artículo sobre formas de probar React.
Enfoques para probar componentes React: una descripción general
” ¿Está usando Mocha, Chai, Supertest lo suficiente?”
¿Qué quieres decir con suficiente? ¿Hay otras herramientas que pueda necesitar? No hay una respuesta directa a esto. Sí, esos son los mínimos 2-3 que probablemente necesitará.
¿Y qué hay de los dobles de prueba? Es posible que necesite crear algunas interfaces para usarlas como simulacros mientras conduce su diseño durante el ciclo TDD … así que solo depende … ¿cómo va a crearlas? Debe considerar si desea usar interfaces naturales (que no existen en JS como lo hacen en un idioma OO) al usar algo como Flow o si quiere usar Sinon, etc.
También depende de su enfoque con TDD. ¿Vas de afuera hacia adentro? Si es así, qué tan afuera está comenzando en sus pruebas. Cuando digo ” afuera ” quiero decir a qué nivel alto estás comenzando a probar tu código (¿cuál es tu contrato)?
¿Qué quiero decir con contrato ? Es la API pública o, en el caso de una interfaz de usuario web, que utiliza pruebas para eliminar su diseño para la capa Vista.
¿Estás comenzando con una prueba de aceptación aislada? Podría usar supertest y no hacer que hable con la red y usarlo para llamadas realmente burlonas a su API, cosas así o podría usar supertest para pruebas de integración que sí llaman a cosas reales como la red (que no sería una unidad prueba pero más bien prueba de integración en ese caso)
pero seguro. Digamos que estás probando una aplicación web. Es posible que también desee usar ayudantes como JSDOM, etc. Hay muchas variables a considerar (qué tipo de aplicación, cuál es su contrato (dónde está comenzando sus pruebas), el estilo de TDD que desea usar, etc.).
Espero que esto no te haya sorprendido. Comience con James Shore primero :).
