test-driven-development

🧪 Test-Driven Development (TDD) Rule

🎯 Objetivo

ALWAYS seguir o paradigma Test-Driven Development (TDD) para código crítico e reutilizável, garantindo que testes sejam escritos ANTES da implementação, seguindo o ciclo Red-Green-Refactor.

🚨 REGRA PRINCIPAL - TEST-FIRST 🚨

ALWAYS escrever testes ANTES da implementação quando:

• ✅ Criando nova função helper/utility (em Utils/ ou Helpers/)
• ✅ Implementando lógica de negócio (cálculos, validações, transformações)
• ✅ Criando novos motores (*Motor.cpp - PointBuy, Multiclass, RaceBonus)
• ✅ Criando novos validators (*Validator.cpp)
• ✅ Adicionando cálculos complexos (modificadores, proficiências, atributos)
• ✅ Implementando regras de negócio (regras D&D, multiclassing, point buy)
• ✅ Refatorando código crítico (escrever testes primeiro para garantir comportamento)

NEVER implementar código crítico sem testes correspondentes.

🔄 O Ciclo Red-Green-Refactor

1. Red: Escrever Teste que Falha

ALWAYS começar escrevendo o teste que define o comportamento esperado:

// ✅ CORRETO - Teste primeiro
BEGIN_DEFINE_SPEC(FPointBuyMotorSpec, "MyProject2.CreateSheet.PointBuy",
                  EAutomationTestFlags::ProductFilter | EAutomationTestFlags::ApplicationContextMask)
    FPointBuyMotor* Motor;
END_DEFINE_SPEC(FPointBuyMotorSpec)

void FPointBuyMotorSpec::Define()
{
    Describe("CalculatePointBuyCost", [this]()
    {
        It("deve calcular custo correto para score 15 (9 pontos)", [this]()
        {
            // Arrange
            int32 Score = 15;

            // Act
            int32 Result = FPointBuyMotor::CalculatePointBuyCost(Score);

            // Assert
            TestEqual("Custo para score 15 deve ser 9", Result, 9);
        });
    });
}

Por que começar pelo teste:

• Define o contrato antes da implementação
• Força pensar na interface primeiro
• Garante que o teste pode detectar erros
• Confirma que a infraestrutura de teste funciona