Master Class - Testing basado en pilares

Nos pagan por escribir código que funciona no por escribir test — Kent Beck

No sé si esto te ha pasado, pero es una de las cosas más frustrantes en desarrollo de software.

Ponte en situación.

Tú quieres hacer las cosas bien porque te preocupa la calidad del software que creas. Y sabes que escribir tests automáticos es el camino correcto.

Te has formado viendo cursos testing en YouTube y artículos en internet. O lo mismo te has venido arriba y te has comprado algún libro o incluso un curso de testing.

Llega la hora de poner en práctica todo lo aprendido. Te pones a escribir tests y escribes muchos tests.

Todo pinta fenomenal.

Tienes hasta un servidor de integración continua y los tests están todos en verde.

Sin embargo, algo falla.

La aplicación es inestable y tiene muchos errores.

En esta situación es normal pensar: ¿de qué me sirve dedicar tanto tiempo al testing si no consigo estabilizar la aplicación y confiar en mis tests?

Encima ahora tienes una cantidad enorme de tests que se rompen con facilidad y que hay que mantener.

En esta situación algo debemos estar haciendo mal si no podemos confiar en nuestros tests y nos están dando más problemas que alegrías.

¿Cuál es el problema?

Escribir muchos tests no es sinónimo de escribir unos buenos tests en los que confiar.

Hay una serie de claves a la hora de decidir qué tests escribir y cuantos escribir.

El objetivo debería ser escribir tests que nos den la máxima confianza en la aplicación con el menor desperdicio y que sean sostenibles en el tiempo.

Para conseguir el menor desperdicio es importante centrarse en los pilares de la aplicación.

Para que sean sostenibles en el tiempo es fundamental no acoplarnos a las implementaciones de nuestro software.

Deberíamos escribir los tests mínimos que nos den la máxima confianza, pero no más.

En mis proyectos yo uso un sistema de testing basado en pilares.

¿Qué se consigue con este sistema?, escribir el mínimo de tests que nos den la máxima confianza en la aplicación con el menor desperdicio y que sean sostenibles en el tiempo.

Este sistema lo voy a contar en una master class que voy a poner a la venta próximamente.

En estos más de 20 años que llevo trabajando, como desarrollador de software, he podido ver de primera mano lo que es frustrarse con los test.

Yo en mis primeros años no tenía ni idea de hacer tests.

Recuerdo, una vez me metieron a añadir tests, es un proyecto. La idea era ganar confianza en lo que estábamos haciendo y reducir el tiempo de pruebas manuales. Conseguí todo lo contrario. Test que daban falsos errores y dedicábamos mucho tiempo a mantenerlos. Trajeron mucha incertidumbre y desconfianza.

Sé, lo que es crear tests frágiles que se rompen con mucha facilidad.

He pasado por ahí y con el paso de los años fui aprendiendo a base de errores.

He hecho mucha consultoría en empresas, he impartido muchas formaciones de testing en empresas.

Todo eso durante muchos años te curte mucho y vas aprendiendo. Llego un punto donde me di cuenta de que más no significa mejor.

Desde hace años uso un sistema de testing basado en pilares donde lo fundamental es probar lo importante.

¿Qué se consigue con esto?

Escribir el mínimo de tests que te den la máxima confianza con el menor desperdicio y que sea sostenible en el tiempo.

He decidido crear una master class donde te voy a contar este sistema. Esto es algo que nadie más te puede contar por qué está basado en mi experiencia de estar en el barro muchos años.

Te cuento para que lo mires con calma.

√  Aprenderás un sistema de testing que puedes aplicar en cualquier lenguaje y cualquier tecnología

√  Aprenderás a escribir menos tests pero de más calidad

√  Aprenderás cómo escribir tests que generen la máxima confianza

√  Aprenderás cómo escribir tests que generen el menor desperdicio

√  Aprenderás cómo optimizar tu tiempo dedicándolo solo a los tests que aportan más valor

√  Cómo enfocar los tests para que no se rompan con facilidad

√  En lo que jamás debes enfocarte al crear tests. Siento decirte que, posiblemente, lo estés haciendo o lo pienses hacer.

√  Te contaré las 2 principales causas que te llevan a escribir tests que no necesitas

√  Aprenderás la clave para crear tests que no sean frágiles

√  Enseñaré código de proyectos reales

√  Te contaré la infraestructura que uso para conseguirlo

√ Te contaré las librerías que he usado en diferentes tecnologías

√  Verás que no se tiene porque escribir tests de toda tu base de código

√  Verás cómo esto se puede aplicar a cualquier tipo de software que desarrolles

√  Evitarás uno de los errores más habituales al escribir tests

HAY ALGO QUE NO TE ESPERAS:

La masterclass dura 1 hora, 48 minutos y 25 segundos.

Hay un video de introducción de 4 min y 41 segundos.

Pero hay 13 minutos donde te contaré los 2 principales problemas que existen para crear tests que no aportan confianza y generan mucho desperdicio.

Te enseño proyectos reales open source, donde podrás ver como lo aplico y que podrás ir a ver cuando quieras.

Y un proyecto privado del que veremos código, pero no puedo decir el nombre ni el cliente. Solo te puedo decir que es un cliente muy grande, más de lo que imaginas.

¿Qué incluye?

Una master class de menos de dos horas que puede ahorrarte años de frustraciones.

En menos de 2 horas te voy a contar algo que a mí me llevo años aprender y está basado en mi experiencia.

¿Cómo es el material?

Te lo he preparado en dos vídeos, uno de 1 hora, 48 minutos y 25 segundos y un otro extra de introducción de 4 min y 41 segundos.

Además, incluye un PDF donde te detallo las librerías que yo he utilizado en diferentes tecnologías para aplicar testing basado en pilares.

¿Para qué perfil de desarrollador está enfocado?

Desarrolladores que ya han empezado a escribir tests, se han dado cuenta de que no es una tarea fácil.

Desarrolladores que se han topado con la frustración de tener test frágiles, que requieren mucho esfuerzo de mantenimiento y generan poca confianza

¿Está la master class enfocada en algún lenguaje o tecnología?

No, es un conocimiento general de una forma de abordar el testing que podrás aplicar en cualquier lenguaje o tecnología.

Y también da igual si te dedicas al frontend, backend, mobile, etc.

¿Hay garantía tía de devolución?

No