WIKI DE AUTOESTUDO • ES06

Aula 7 — Orientação a Objetos com TDD

Guia completo: POO, SOLID, Arquitetura e Engenharia com IA (AIOX)
Acessar Slides Plano de Ensino ← Voltar ao Módulo

1. Introdução e Contexto

A engenharia de software passou por uma revolução silenciosa, mas drástica: a Inteligência Artificial Generativa. Hoje, digitar código deixou de ser a atividade que mais consome o tempo de um engenheiro. Contudo, IAs não entendem profundamente os contratos arquiteturais de grandes sistemas corporativos. Se deixadas "soltas" para codificar, elas criam atalhos lógicos (alucinações arquiteturais) que destroem o isolamento, a segurança e a testabilidade das aplicações.

O papel do engenheiro moderno, portanto, migrou de "digitador" para arquiteto e modelador. Para garantir que as ferramentas de IA gerem código de alta qualidade, precisamos estabelecer barreiras — os famosos Guardrails. E a melhor barreira disponível no mercado atual é a combinação de Testes Unitários e Design Orientado a Objetos.

2. Fundamentos: POO e SOLID

A Programação Orientada a Objetos (POO) é o paradigma base que torna a arquitetura de grandes aplicações viável. Em vez de termos funções procedurais espalhadas, nós encapsulamos estados (variáveis) e comportamentos (métodos) dentro de "Objetos". A POO sustenta 4 pilares:

Os Princípios SOLID

Para evitar que a POO vire uma "sopa de objetos", usamos o SOLID. Nos testes (e no contexto de IA), destacam-se dois:

3. Modelagem: Dinâmica e Estática

Numa Arquitetura Orientada a Serviços (SOA), a comunicação precisa ser altamente restrita por contratos.

Modelagem Estática: Define O QUE existe no sistema. São os Diagramas de Classes (UML). Define os atributos, os métodos públicos e de quem a classe depende.

Modelagem Dinâmica: Define COMO o sistema interage no tempo. São os Diagramas de Sequência e Casos de Uso. Revela as regras de negócio reais, fluxos condicionais e lógicas.

Antes de escrever uma linha de código, a modelagem dita a arquitetura. Mas como obrigar a IA a respeitar o UML? É aí que entra o TDD.

4. TDD como Guardrail

O Test-Driven Development (TDD), concebido na década de 1990, prega o ciclo de escrever o teste que falha antes da implementação que passa. Historicamente o ciclo é:

  1. Red: Escreva um teste que consuma a classe imaginada. Ele vai falhar ou sequer compilar, pois a classe ainda não existe.
  2. Green: Escreva o código mínimo e sujo na implementação apenas para fazer a barra do teste ficar verde.
  3. Refactor: Limpe a implementação, melhore a performance, mantendo a barra verde.

A Revolução da IA: No cenário atual, nós humanos ficamos com a etapa Red. Traduzimos o nosso diagrama UML e regras de negócio estritas para dentro do teste. Uma vez que o "Guardrail" (barreira) está criado, nós engatamos a IA (AIOX) para fazer o passo Green. Se a IA alucinar funções, instanciar classes erradas ou ignorar a Injeção de Dependência, o teste quebra e o AIOX refaz até acertar, garantindo o respeito arquitetural absoluto.

O Padrão AAA no xUnit

Todo teste bem estruturado no .NET (`xUnit`) é dividido em 3 atos:

5. Mocks, Stubs e Fakes

Se o TDD isola a classe, como ela interage com banco de dados ou APIs no teste? Usamos Dublês de Teste (Test Doubles).

6. Mão na Massa: Passo a Passo com AIOX

Imagine que precisamos criar uma CalculadoraScoreUsuario que consome um IUserRepository. Veja o fluxo:

Passo A: O Humano cria a Trava (Red)

Nós programamos o xUnit e usamos Moq para travar a arquitetura:

using Moq;
using Xunit;

public class CalculadoraScoreTests
{
    [Fact]
    public void DeveRetornarScore100_QuandoUsuarioAtivo()
    {
        // Arrange
        var repoMock = new Mock<IUserRepository>();
        repoMock.Setup(r => r.GetStatus(1)).Returns("Ativo");
        
        // Exigimos Injeção de Dependência! A IA é obrigada a criar esse construtor.
        var calc = new CalculadoraScoreUsuario(repoMock.Object);

        // Act
        var score = calc.Calcular(1);

        // Assert
        Assert.Equal(100, score);
        repoMock.Verify(r => r.GetStatus(1), Times.Once); // Trava o comportamento
    }
}

Passo B: A IA entra em cena (AIOX / Green)

Em vez do desenvolvedor gastar tempo codando a classe, rodamos a CLI no terminal:

# Instalação do AIOX no projeto atual
$ npx aiox-core@latest install

# Rodar a AI para resolver o problema baseando-se nas falhas dos testes
$ aiox run dev --test-path tests/CalculadoraScoreTests.cs

O AIOX vai ler a falha, inferir o UML e gerar o código em C# da classe CalculadoraScoreUsuario com o construtor requerendo um IUserRepository e o método retornando 100 se a chamada de status der "Ativo". Sua arquitetura foi protegida!

7. Glossário de Termos

AIOX
Ferramenta em CLI desenvolvida para automatizar etapas de Engenharia de Software integrando habilidades de IA (Skills) nos pipelines de QA e Dev.
Guardrail
No contexto de IA Generativa, são "grades de proteção" que impedem o agente de fugir das regras preestabelecidas. O TDD atua como um guardrail algorítmico.
Zero-shot / Few-shot Prompting
Estratégias de IA. "Zero-shot" é pedir algo à IA sem dar exemplos. "Few-shot" inclui prover contexto (como um Diagrama ou Testes) para ancorar matematicamente a geração do token correto.
xUnit
Framework padrão de testes unitários para o ecossistema .NET e C#. Substitui o antigo MSTest e o NUnit em grande parte da indústria.
Moq
Uma das bibliotecas mais famosas no universo C# para criação de Mocks e Dublês de teste, caracterizada por ser fortemente tipada e usar Expressões LINQ.
SOA (Service-Oriented Architecture)
Estilo de arquitetura de software onde os componentes de aplicações provêm serviços a outros componentes via um protocolo de comunicação, usualmente sobre uma rede.

Leituras e Referências Extras