Pruebas automatizadas: TDD y BDD en la práctica

Las pruebas son la base de un software confiable. Cuando se aplican bien, reducen los errores, aumentan la velocidad de entrega y dan confianza para refactorizar. Dos paradigmas populares son el Desarrollo basado en pruebas (TDD) y el Desarrollo basado en comportamiento (BDD). Aunque complementarios, tienen enfoques diferentes.

Cuándo usar TDD frente a BDD

TDD: centrarse en unidades de código (funciones, clases). La prueba se escribe antes de la implementación, asegurándose de que la API pública se comporte como se espera.
BDD: centrarse en el comportamiento de alto nivel (flujos de usuarios, requisitos). Utiliza un lenguaje casi natural (Gherkin) para describir escenarios.

Regla general: utilice TDD para lógica empresarial y bibliotecas internas; Utilice BDD para flujos e integraciones de UI.

Herramientas recomendadas

Capa	Herramienta	Por qué utilizar
Unitario (JS/TS)	Broma	Pruebas rápidas e instantáneas, cobertura integrada
Unitario (Nodo)	Moca + Chai	Integración flexible y buena con Sinon
UI (Reaccionar)	Biblioteca de pruebas	Pruebe la interfaz de usuario tal como la ve el usuario
De extremo a extremo	Ciprés	Pruebas reales de navegador, depuración visual
BDD	Pepino.js	Sintaxis de Gherkin, integración Jest/Cypress

Flujo TDD paso a paso

Escribe la prueba que falla (rojo).
Implementar código mínimo para aprobar (verde).
Refactor manteniendo las pruebas en verde (refactor).
Repetir.

Ejemplo práctico, función de formato de precios

// priceFormatter.test.ts (Jest)
import { formatPrice } from './priceFormatter';

test('formata número como moeda BRL', () => {
  expect(formatPrice(1234.5)).toBe('R$ 1.234,50');
});

// priceFormatter.ts (implementação mínima)
export function formatPrice(value: number): string {
  return new Intl.NumberFormat('pt-BR', { style: 'currency', currency: 'BRL' }).format(value);
}

Flujo BDD con Cucumber.js

Definición de escenario (pepinillo)

Feature: Cadastro de Usuário
  As a visitor
  I want to create an account
  So that I can access protected features

  Scenario: Cadastro bem-sucedido
    Given I am on the registration page
    When I fill the form with valid data
    And I submit the form
    Then I should see a confirmation message
    And I receive a verification email

Implementación de pasos (Ciprés + Pepino)

import { Given, When, Then } from 'cypress-cucumber-preprocessor/steps';

Given('I am on the registration page', () => {
  cy.visit('/register');
});

When('I fill the form with valid data', () => {
  cy.get('#email').type('usuario@example.com');
  cy.get('#password').type('SenhaForte123!');
  cy.get('#confirmPassword').type('SenhaForte123!');
});

When('I submit the form', () => {
  cy.get('form').submit();
});

Then('I should see a confirmation message', () => {
  cy.contains('Cadastro concluído').should('be.visible');
});

##Buenas prácticas generales

Mantenga las pruebas rápidas: si una prueba tarda más de 500 ms, probablemente esté realizando E/S innecesarias.
Aislamiento: utilice simulacros/stubs para dependencias externas (API, bancos).
Cobertura mínima: una cobertura de línea del 80% es un buen punto de partida, pero priorice la lógica crítica.
Integración continua: configurar el pipeline (GitHub Actions, GitLab CI) para ejecutar npm test en cada PR.
Comentarios visuales: utilice complementos IDE que muestren resultados de pruebas en tiempo real.

Lista de verificación de implementación

[] Elija el marco de prueba (Jest, Cypress, etc.)
Configurar jest.config.js y cypress.json
Crear directorios tests/unit y tests/e2e
[] Escribe la primera prueba fallida para cada característica nueva
[] Integrar pruebas en el proceso de CI
[] Monitorear fallas de cobertura y respaldo

Conclusión

TDD y BDD no son sólo técnicas, son cambios de mentalidad. Cuando se adoptan correctamente, garantizan que su código evolucione sin temor a alterar la funcionalidad existente. Empiece poco a poco, escriba pruebas claras y deje que ellas guíen su desarrollo.

¿Cuál es tu experiencia con TDD o BDD? ¡Comparte en los comentarios!