Test-Driven Development e sua influência no design

Test-Driven Development e
sua Inﬂuência no Design
Mauricio Aniche
http://www.aniche.com.br

Test-driven development (TDD) is the craft of producing
automated tests for production code, and using that
process to drive design and programming. For every tiny
bit of functionality in the production code, you ﬁrst
develop a test that speciﬁes and validates what the code
will do.You then produce exactly as much code as will
enable that test to pass.Then you refactor (simplify and
clarify) both the production code and the test code.

www.agilealliance.org/programs/roadmaps/Roadmap/tdd/tdd_index.htm

mas todo mundo
já sabe que tdd é sobre
design!

TDD mostra o
problema, mas não
resolve pra você!

[TestFixture]
public class GeradorDeNotaFiscalTest
{
[Test]
public void DeveGerarUmaNotaFiscal {
var gerador = new GeradorDeNotaFiscal();
var nf = gerador.gera(fatura);
Assert.AreEqual(fatura.Valor * 0.2, nf.ValorImposto);
}
}

- hmm... ele depende de algo?
- deve receber uma fatura?
- o nome do método está claro?
- o que ele deve retornar?

[TestFixture]
{
[Test]
public void DeveGerarUmaNotaFiscalEAgruparPorAliquota {
var notas = gerador.gera(faturaComServicosComAliquotasDiferentes());
Assert.AreEqual(1, notas.Count);
}

[Test]
public void DeveGerarUmaNotaFiscalEAgruparPorSerie {
var notas = gerador.gera(faturaComServicosComSeriesDiferentes());
}
} hmm... esse agrupamento é complicado!
a implementação tá confusa por causa
dele...
já sei! vou extrair!

[TestFixture]
{
[Test]
public void DeveGerarUmaNotaFiscal {
var agrupador = new Mock<IAlgoritmoDeAgrupamento>();
var gerador = new GeradorDeNotaFiscal(agrupador.Object);
var notas = gerador.gera(fatura);
}
}

nice!

public class Carro
{
public Carro ()
{
}
}

public class Carro
{
private Pneus pneuDianteiro;

public Carro (Pneus pneuDianteiro)
{
this.pneuDianteiro = pneuDianteiro;
}
}

public class Carro
{
private Pneus pneuTraseiro;

public Carro (Pneus pneuDianteiro, Pneus pneuTraseiro)
{
this.pneuTraseiro = pneuTraseiro;
}
}

public class Carro
{
private Suspensao suspensao;

public Carro (Pneus pneuDianteiro, Pneus pneuTraseiro, Suspensao
suspensao)
{
this.suspensao = suspensao;
}
}

public class Carro
{
private Motor motor;

suspensao, Motor motor)
{
this.motor = motor;
}
}

public class Carro
{
private Freio freio;

suspensao, Motor motor, Freio freio)
{
this.motor = motor;
this.freio = freio;
}
}

public class Carro
{
private CaixaDeCambio caixaDeCambio;

suspensao, Motor motor, Freio freio, CaixaDeCambio caixaDeCambio)
{
this.motor = motor;
this.freio = freio;
this.caixaDeCambio = caixaDeCambio;
}
}

public class Carro
{
private Combustivel combustivel;

suspensao, Motor motor, Freio freio, CaixaDeCambio caixaDeCambio,
Combustivel combustivel)
{
this.motor = motor;
this.freio = freio;
this.combustivel = combustivel;
}
}

public class Carro
{
private Renavam renavam;

Combustivel combustivel, Renavam renavam)
{
this.motor = motor;
this.freio = freio;
this.renavam = renavam;
}
}

public class Carro
{

Combustivel combustivel, Renavam renavam, ...)
{
this.motor = motor;
this.freio = freio;
// ...
}
}

Mas quando você
aprende a usar...

Vou mostrar como
eu vejo o feedback
dos testes.

Bloated constructor
Sintoma: A classe possui um alto acoplamento, e isso pode ser
visto através do número de parâmetros que a classe recebe no
construtor, por exemplo.
[TestFixture]
public class MessageProcessorTest
{
// atributos com as dependencias que serao mockadas

[SetUp]
public void SetUp() {
// criando mocks
}

[Test]
public void ShouldDoSomething()
{
var processor = new MessageProcessor(unpacker, auditer, locationFinder,
counterPartyFinder, domesticNotifier, importedNotifier);
processor.OnMessage(BuildSomeSpecificRawMessage());
// algumas assercoes aqui..
}
}

Bloated constructor
public class MessageProcessor
{

public MessageProcessor(MessageUnpacker unpacker,
AuditTrail auditer,
CounterPartyFinder counterpartyFinder,
LocationFinder locationFinder,
DomesticNotifier domesticNotifier,
ImportedNotifier importedNotifier) {
// seta os atributos aqui
}

public void OnMessage(Message rawMessage) {
UnpackedMessage unpacked = unpacker.Unpack(rawMessage, counterpartyFinder);
auditer.RecordReceiptOf(unpacked);
// alguma outra atividade aqui
if (locationFinder.IsDomestic(unpacked)) {
domesticNotifier.Notify(unpacked.AsDomesticMessage());
} else {
importedNotifier.Notify(unpacked.AsImportedMessage());
}
}
}

Bloated constructor
{

AuditTrail auditer,
LocationFinder locationFinder,
DomesticNotifier domesticNotifier,
ImportedNotifier importedNotifier) {
}

UnpackedMessage unpacked = unpacker.Unpack(rawMessage);
// some other activity here
if (locationFinder.IsDomestic(unpacked)) {
domesticNotifier.Notify(unpacked.AsDomesticMessage());
} else {
importedNotifier.Notify(unpacked.AsImportedMessage());
}
}
}

Bloated constructor
{

AuditTrail auditer,
MessageDispatcher dispatcher) {
}

UnpackedMessage unpacked = unpacker.Unpack(rawMessage);
// alguma outra atividade aqui
dispatcher.Dispatch(unpacked);
}
}

public class Carro
{

public Carro (Pneus pneuDianteiro, Pneus pneuTraseiro, Suspensao suspensao,
Motor motor, Freio freio, CaixaDeCambio caixaDeCambio, Combustivel combustivel, ...)
{
this.motor = motor;
this.freio = freio;
...
}
}

dependencies,
notiﬁcations,
adjustments

public class Carro
{

public Carro (Renavam renavam)
{
this.pneuDianteiro = Pneus.Firestone();
this.pneuTraseiro = Pneus.Michellin();
this.suspensao = Suspensao.AMelhor();
this.motor = Motor.DezesseisValvulas();
this.freio = Freio.ABS();
this.caixaDeCambio = CaixaDeCambio.Automatica();
this.combustivel = Combustivel.Flex();
}

public Carro (Pneus pneuDianteiro, Pneus pneuTraseiro, Suspensao suspensao,
Motor motor, Freio freio, CaixaDeCambio caixaDeCambio, Combustivel combustivel, Renavam
renavam)
{
// seta os atributos
}

}

use um builder!
new CarroBuilder().ComPneu(Pneus.Firestone).ComMotor(Motor.Zetec).[...].Cria();

by @cv

Mocks de mocks de mocks...
Sintoma: Você precisa fazer mocks de mocks (de mocks ...)
para conseguir testar o que precisa.
[TestFixture]
    public class AcceptPostPutAndPatchVerbsTests
    {
        // atributos

[SetUp]
        public void SetupAContext()
        {
            httpContext = new Mock<HttpContextBase>();
            httpRequest = new Mock<HttpRequestBase>();
            requestContext = new RequestContext(httpContext.Object, new RouteData());
            controllerContext = new ControllerContext(httpContext.Object, new RouteData(), new
SomeController());
            httpContext.Setup(h => h.Request).Returns(httpRequest.Object);
            context = new ActionExecutingContext(controllerContext, new
Mock<ActionDescriptor>().Object, new RouteValueDictionary()) { RequestContext = requestContext };
        }

[Test]
        public void ShouldAcceptPost()
        {
            httpRequest.Setup(h => h.HttpMethod).Returns("POST");

            Assert.IsTrue(new AcceptPostPutAndPatchVerbs().IsValid(context));
        }
    }

Lei de Demeter
[nada de A.B.metodoC() ...]

Cuidado com herança
Lembre-se do Princípio de Substituição de Liskov (LSP)

Mocks que não são usados
diretamente pelo teste
Sintoma: Você passa um mock, seta uma expectativa para ele,
mas acaba não os usando nas asserções do teste.

[TestFixture]

public class GeradorDeNotaFiscal

public class GeradorDeNotasFiscaisTest

{

{

[SetUp]

public GeradorDeNotaFiscal

public void SetUp() {
(InformacoesFiscais info, Sap sap,

sap = new Mock<SAP>();
EnviadorDeEmail emails)

emails = new Mock<EnviadorDeEmail>();

{

info = new Mock<InformacoesFiscais>();

// seta atributos

gerador = new GeradorDeNotaFiscal(info,

}
sap.Object, emails.Object);

}

public NotaFiscal Gera(Fatura fatura) {

var nota = geraNotaUsandoInfo();

[Test] public void DeveEnviarAoSap () {


sap.EnviaNota(nota);

sap.Verify(s => s.EnviaNota(nf),

emails.EnviaNota(nota);
Times.Once());

}

}

}

[Test] public void DeveEnviarOEmail () {


emails.Verify(s => s.EnviaNota(nf),
Times.Once());

}}

Single Responsibility
Principle (SRP)
(A classe deve ter apenas uma responsabilidade)

public class GeradorDeNotaFiscal

{

private IList<IObservadorDeNotaGerada> observadores;

public GeradorDeNotaFiscal (InformacoesFiscais info)

{

// seta atributos

}

public void AdicionaObservador(IObservadorDeNotaGerada observador) { ... }

private void Notifica(NotaFiscal nota) {

foreach(var observador in observadores) {
observador.notifica(nota);
}

}

public NotaFiscal Gera(Fatura fatura) {

var nota = geraNotaUsandoInformacoesFiscais();

Notifica(nota);

}

}

O teste mostra, mas quem
refatora (para padrões) é você!

Intimidade Inapropriada
Sintoma: Você testa classes (geralmente com o péssimo suﬁxo
“Service”) que praticamente só lidam com uma classe especíﬁca.

[TestFixture]

public class EmiteBoletoServiceTest

{

[Test]

public void DeveMarcarOBoletoComoEmitido ()

{

var service = new EmiteBoletoService();

var boleto = new Boleto { Pago = true };

service.Emite(boleto);

Assert.AreEqual(true, boleto.Emitido);

}

}

public class EmiteBoletoService

{

public Emite(Boleto boleto) {

if(boleto.Pago) {

boleto.Emitido = true;

}

}

}

Tell, Don’t Ask!
(Você deve dizer ao objeto o que quer que ele faça!)

Cuidado com interfaces que
interagem somente com o
mesmo objeto!

public interface BoletoService

{

void Emite(Boleto boleto);

void Paga(Boleto boleto);

void Cancela(Boleto boleto);
...

}

Testando combinações
Sintoma: Os testes passam a ﬁcar complicados e você passa a
testar diferentes combinações de entradas.

public IList<Fatura> PegaFaturas() {

var lista = repositorio.PegaTodasFaturas();

lista = RemoveAntigas(lista);

lista = RemovePagas(lista);

lista = RemoveQuemTemContatoComercial(lista);

return lista;
}

[Test]

public void DeveRemoverAntigas() {

MockaRepositorioParaDevolvarListaComFaturasAntigas();

var lista = PegaFaturas();

Assert.VerificaQueSóTemFaturasAntigas();
}

[Test]

public void DeveRemoverPagas() {

MockaRepositorioParaDevolvarListaComFaturasPagas();

var lista = PegaFaturas();

Assert.VerificaQueSóTemFaturasPagas();
}

...

public IList<Fatura> PegaFaturas() {

var lista = repositorio.PegaTodasFaturas();

return new RemoveAntigas(
new RemovePagas(
new RemoveQuemTemContatoComercial())).Filtra(lista);
}

public class RemoveAntigas : FiltroDeFatura {

public RemoveAntigas(FiltroDeFatura) { ... }

public RemoveAntigas() { ... }

public Filtra(IList<Fatura> faturas) {
// filtra e passa para o proximo!
}
}

...

Objetos insubstituíveis
Sintoma: Você precisa mockar um objeto que não é
substituível sem mágica!

[Test]

public void DeveEmitirAPassagemComADataAtual() {

var passagem = new GeradorDePassagem().Emite();

Assert.AreEqual(DateTime.Now, passagem.DataEmissao);
}

public class GeradorDePassagem {

public Passagem(IRelogio relogio) { ... }

public Passagem Emite(Passageiro passageiro) {
var data = relogio.DataAtual;
// faz alguma coisa com a data...
}
}

[Test]

public void DeveEmitirAPassagemComADataAtual() {

var agora = DateTime.Now;

relogio.SetupGet(r => r.DataAtual).Returns(agora);

var passagem = new GeradorDePassagem(relogio).Emite();

Assert.AreEqual(agora, passagem.DataEmissao);
}

Nomenclatura ajuda!
Sintoma: O nome da classe e/ou seus métodos não fazem
sentido para o domínio!

[Test]

public void DeveFazerAlgumaCoisa() {

var entidade = new GerenciadorServiceImpl(new PassagemDAO()).FazTarefa();
}

If’s e switches
Sintoma: Você tem testes muito parecidos que geram
resultados diferentes, e quando olha a implementação, ela tem
um if ou switch.

[Test]

public void CalculaISS() {

var valor = new CalculaImposto().ParaValor(1500);

Assert.AreEqual(1500*1.2, valor);
}

[Test]

public void CalculaICMS() {

var valor = new CalculaImposto().ParaValor(6000);

Assert.AreEqual(6000*1.3, valor);
}

public class CalculaImposto {

private TipoImposto tipo;

public CalculaImposto(TipoImposto tipo) {
this.tipo = tipo;
}

public double ParaValor(double valor) {
if(valor < 1000) {
return valor * 1.1;
}
else if(valor > 1000 && valor < 5000) {
return valor * 1.2;
}
else if (valor >= 5000 && valor < 8000) {
return valor * 1.3;
}
else { ... }
}
}

Elimine if’s e switches na
medida do possível!

Padrões de projeto podem
ajudar (de novo)!

Brain classes
Sintoma: Você tem uma classe de teste muito grande.

[Test]
public void DeveFazerX1() { ... }

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]

[Test]
public void DeveFazerXn() { ... }

A mesma coisa se você tem um
cenário muito grande para um
simples teste!

A mesma coisa se você achar
que precisa testar um método
privado!

Quebre essa classe em
pequenas outras classes!
(lembre do SRP novamente!)

Mas é assim que
eu interpreto!

Você pode achar outras
maneiras de interpretar!
e se achar, me conta! ;)

"Every pattern describes a problem which occurs over
and over again in our environment, and then describes
the core of the solution to that problem, in such a way
that you can use this solution a million times over,
without ever doing it the same way twice."

Christopher Alexander, "The Pattern Language"

Ouça seus testes!
deu pra ver o quanto eles têm pra contar?

Referências
- Freeman, S.; Pryce, N. “Growing Object Oriented Software, Guided By Tests.”
- Beck, K. “Test-Driven Development by Example”
- Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. “Design Patterns: Elements of
Reusable Object-Oriented Software”
- Feathers, M. “Working Effectively with Legacy Code”
- Martin, R. “Agile Principles, Patterns, and Practices in C#”
- Martin, R. “Clean Code”

Test-Driven Development e sua influência no design

Mais conteúdo relacionado

Destaque

Semelhante a Test-Driven Development e sua influência no design

Mais de Maurício Aniche

Test-Driven Development e sua influência no design

Notas do Editor