Um bate-papo sobre TDD

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

Um bate-papo sobre Test-Driven Development Mauricio Aniche http://www.aniche.com.br @mauricioaniche

uma enquete bem rapidinha!

o que é TDD?

qual a vantagem disso?

um conjunto de testes de unidade...

e por consequência, segurança!

então TDD é uma prática de testes de software?

livros sobre livros sobre testes de software TDD testes de baby integração steps red- testes green- análise do de refactor valor-limite unidade feedback classes de no design equivalência

ufa, mas hoje todo mundo já sabe!

mas como assim... escrevo testes, mas não quero testar?

faz o programador pensar sobre um monte de coisas...

[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?

... e mudar de ideia é “barato”!

feedback rápido

simplicidade

public class CarrinhoDeCompras { // quais atributos? // quais comportamentos? }

chega de adivinhação!

(mas espera aí que daqui a pouco conversamos sobre isso!)

TDD vai salvar o mundo! (WTF?)

TDD não faz mágica! :-(

mas pra conseguir escrever um teste você...

... deixe as dependências explícitas

... implemente “bons vizinhos”

a voz do povo é a voz de Deus?

mas não é só isso...

TDD mostra os problemas...

... mas quem resolve o problema é você!

mas primeiro precisamos ver o problema!

ser preguiçoso às vezes é bom!

exemplo: como testar uma God class?

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 { [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); // ... if (locationFinder.IsDomestic(unpacked)) { domesticNotifier.Notify(unpacked.AsDomesticMessage()); } else { importedNotifier.Notify(unpacked.AsImportedMessage()); } } }

Bloated constructor public class MessageProcessor { public MessageProcessor(MessageUnpacker unpacker, AuditTrail auditer, LocationFinder locationFinder, DomesticNotifier domesticNotifier, ImportedNotifier importedNotifier) { // seta os atributos aqui } public void OnMessage(Message rawMessage) { UnpackedMessage unpacked = unpacker.Unpack(rawMessage); auditer.RecordReceiptOf(unpacked); // ... if (locationFinder.IsDomestic(unpacked)) { domesticNotifier.Notify(unpacked.AsDomesticMessage()); } else { importedNotifier.Notify(unpacked.AsImportedMessage()); } } }

Bloated constructor public class MessageProcessor { public MessageProcessor(MessageUnpacker unpacker, AuditTrail auditer, MessageDispatcher dispatcher) { // seta os atributos aqui } public void OnMessage(Message rawMessage) { UnpackedMessage unpacked = unpacker.Unpack(rawMessage); auditer.RecordReceiptOf(unpacked); // ... dispatcher.Dispatch(unpacked); } }

por falar em dependências...

só diminuir o acoplamento não é suﬁciente!

classes estáveis http://www.aniche.com.br/2010/10/tdd-diminui-o-acoplamento-mas-so-isso-nao-resolve/

boas dependências http://www.aniche.com.br/2010/10/tdd-diminui-o-acoplamento-mas-so-isso-nao-resolve/

e todas dependências são iguais?

você pode então tratá-las de maneiras diferentes!

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 { { public GeradorDeNotaFiscal [Test] public void DeveEnviarAoSap() (InformacoesFiscais info, Sap sap, { EnviadorDeEmail emails) var nf = gerador.gera(fatura); { // seta atributos } sap.Verify(s => s.EnviaNota(nf), Times.Once()); public NotaFiscal Gera(Fatura } fatura) { var [Test] public void nota=geraNotaUsandoInfo(); DeveEnviarOEmail(){ var nf = gerador.gera(fatura); sap.EnviaNota(nota); emails.Verify(s => emails.EnviaNota(nota); s.EnviaNota(nf), Times.Once()); } } } }

classes com baixo acoplamento e alta coesão

public class GeradorDeNotaFiscal { private IList<IObservadorDeNotaGerada> observadores; public GeradorDeNotaFiscal (InformacoesFiscais info) { ... } public void AdicionaObservador(IObservadorDeNotaGerada observador) { ... } private void Notifica(NotaFiscal nota) { ... } public NotaFiscal Gera(Fatura fatura) { var nota = geraNotaUsandoInformacoesFiscais(); Notifica(nota); } }

você já pensou em testar métodos privados? http://www.aniche.com.br/2010/11/voce-quer-testar-metodos-privados-certeza/

extrair classes passa a ser normal! http://www.aniche.com.br/2010/11/voce-quer-testar-metodos-privados-certeza/

a composição tende a ser mais simples que a soma das partes

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! } } ...

simplicidade é essencial!

e o tal dos baby steps?

isso é muito mal interpretado! http://blog.caelum.com.br/2010/11/18/mudancas-simples-x-solucoes-simples/

A mudança mais simples para resolver um problema não é necessariamente a solução mais simples para resolvê-lo. by @mauricioaniche e @guilhermecaelum http://blog.caelum.com.br/2010/11/18/mudancas-simples-x-solucoes-simples/

o problema não é a implementação, e sim o design! http://www.aniche.com.br/2010/11/cuidado-com-seus-baby-steps/

um outro problema, aliás, são os tais singletons!

encapsulamento não é tão fácil quanto parece!

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)); } }

abstração é o segredo!

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; } } }

melhor entendimento dos requisitos (pensou que as vantagens tinham acabado?)

Impl classes are meaningless

Ouça os seus testes! :)

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

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”

Obrigado! Mauricio Aniche http://www.aniche.com.br @mauricioaniche

http://www.aniche.com.br	2472
http://sandysnunes.wordpress.com	155
http://blog.sinhorinho.com	6
http://webcache.googleusercontent.com	2
http://translate.googleusercontent.com	2

Um bate-papo sobre TDD

by mauricioaniche on Nov 21, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 2,637

Statistics

Um bate-papo sobre TDD — Presentation Transcript