"Escribe tests. No demasiados. Principalmente de integraci贸n."

鉁嶐煆 Kent C. Dodds

Si empiezo con esta frase es para introducir la idea de que no hay un s贸lo tipo de test. Y dejar caer que no hay volverse locos probado c贸digo. Es mejor empezar poco a poco, pero empezar. Si ya has empezado, entonces avanza un poco m谩s.

En cualquier caso te vendr谩 bien un repaso de conceptos b谩sicos y nomenclatura.

Tipos de Pruebas

馃 Manuales -> Programadas

  • 鉂 Dependemos de las personas

  • 鉁旓笍 Se pueden configurar y lanzar autom谩ticamente

鈿 T茅cnicas -> Funcionales

  • 鈿 Se puede comprobar el rendimiento, la seguridad, usabilidad...

  • 鉁旓笍 La funci贸n del software, su utilidad.

馃攷 Unitarias -> De integraci贸n -> De inicio a fin

  • 鉁旓笍 unitarias: Pruebas de caja blanca que verifican una funci贸n, una clase o un componente.

  • de integraci贸n: Pruebas de caja blanca que verifican que varios componentes funcionan bien juntos.

  • 鉁旓笍 de inicio a fin: Pruebas de caja negra que replican el comportamiento de un usuario ante un sistema completo.

Otras: de regresi贸n, de humo, de aceptaci贸n...

鈱 Despu茅s -> Durante -> Antes

  • Despu茅s o mucho despu茅s legacy. Es costoso, pero imprescindible para un refactoring y muy habitual en un end to end

  • Durante es aburrido pero necesario para las pruebas de integraci贸n.

  • 鉁旓笍 Antes El conocido como TDD para pruebas unitarias o BDD para las de integraci贸n. Menos costoso, m谩s divertido y con mucho mejor dise帽o resultante.

馃懆鈥嶐煄 Qu茅 hay que saber para programar tests.

1锔忊儯 Mantra

  • El c贸digo de prueba no es como el c贸digo de producci贸n: dis茅帽alo para que sea simple, corto, sin abstracciones, agradable de leer. Uno debe mirar una prueba y obtener la intenci贸n al instante.

2锔忊儯 Siglas y conceptos

  • SUT: System (Subject) Under Test. Lo que se est谩 probando.

  • DOCs: Depended On Components. Lo que se necesita para que funcione el SUT.

3锔忊儯 Secciones: Arrange, Act & Assert (AAA Pattern)

  • Arrange: Prepara y organiza lo que necesitas.

  • Act: Ejecuta el c贸digo y obt茅n una respuesta.

  • Assert: Verifica que la respuesta es la esperada.

4锔忊儯 Cuestiones: Given, Should, Actual, Expected.

  • Given: 馃搩 Texto. Condiciones de la prueba. (Arrange)

  • Should: 馃搩 Texto. Funcionalidad esperada.

  • Actual: 馃幇 Variable. El resultado obtenido. (Act)

  • Expected: 馃挵 Variable. La respuesta esperada. (Assert)

5锔忊儯 Test Doubles: Simuladores para no depender de las dependencias DOC.

  • Dummy: Datos requeridos para que el SUT funcione, pero que no se usan durante la prueba. (Carga previa de una base de datos)

  • Stub: Un objeto que cumpliendo una interfaz de un DOC tiene una respuesta constante y predeterminada. (Responder como lo har铆a un llamada http)

  • Fake: Un objeto que realiza una funcionalidad coherente pero simplificada de un DOC. (Simular una base de datos en memoria)

  • Spy: Cuenta las llamadas a una funci贸n o m茅todo. (Comprobar que se ejecuta una acci贸n un determinado n煤mero de veces)

  • Mock: Monitoriza el uso de un objeto y las llamadas a una funci贸n junto con sus argumentos. (Simular un env铆o de correo completo)

6锔忊儯 Comprobaciones: igualdad, existencia, comparaci贸n, pertenencia, excepciones y negaci贸n

  • igualdad: El valor actual es igual al esperado.

  • existencia: El valor actual existe.

  • comparaci贸n: El valor actual es mayor o menor que el esperado.

  • pertenencia: El valor actual contiene o est谩 contenido en el esperado.

  • excepciones: Se espera que una excepci贸n sea lanzada.

  • negaci贸n: Niega cualquiera de los anteriores.

7锔忊儯 Consejos generales

  • incorpora herramientas: Puedes empezar de cero, pero hay muchas ayudas.

  • evita arreglos globales: Cada prueba deber ser aut贸noma e independiente.

  • datos realistas en los fakes: Nada de foo bar baz asdf

  • usa etiquetas o c贸digos: 脷til para buscar resultados o pre filtrar pruebas.

  • public black box: Prueba los m茅todos p煤blicos.

  • evita los mocks: Mejor usa Stubs y Spies.

  • haz alguna prueba: Esto no va de todo o nada.

馃洜 Herramientas

  • Utilidades para probar aplicaciones desarrolladas con tecnolog铆a web.

Puppeteer

Puppeteer es excelente para manipular y simular cualquier actividad con el navegador ideal para e2e no funcional.

Cypress

Cypress es un framework de pruebas funcionales de integraci贸n o e2e. Se ejecuta en el navegador independiente del c贸digo bajo prueba.

Jest

JEST es un framework muy popular porque requiere zero configuration. Es muy ligero y sencillo. Ideal para unit testing y TDD.

Otros

  • Playwright automatizador de diversos navegadores al estilo Puppeteer.

  • Karma es un ejecutador de pruebas muy interesante para integraci贸n continua.

  • Jasmine muy completo y bueno para user-behavior por su expresividad

  • Mocha muy utilizado para NodeJS.

  • Chai librer铆a muy adecuada para BDD con NodeJS.