Nós
amamos
métodos ágeis
Mas tudo faz sentido...
Será que vale a pena
Homens de nível educacional mais alto apresentaram maior quantidade de sintomas pseudoneuróticos do que aqueles que haviam recebido menos instrução; Homens do meio rural mantiveram-se mais bem-humorados durante a guerra do que os soldados recrutados nas cidades;
A capacidade dos homens do Sul (dos EUA) para
suportar o calor era maior do que as dos soldados do Norte.
Nossa
intuição
Mas nós
conhecemos
bem de software, não
O que é TDD?
•
Qual a melhor definição sobre TDD?•
“Prática onde o desenvolvedor escrevetestes antes da implementação”
•
“Prática onde o desenvolvedor escreveTest-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 first
develop a test that specifies 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.
TDD como
prática de testes
•
Quando o desenvolvedor pratica TDD comA academia gosta disso...
Como prática de teste
Como prática de teste
•
Tem vantagem?Como prática de teste
•
Tem vantagem?•
Código “nasce testado”Como prática de teste
•
Tem vantagem?•
Código “nasce testado”•
Menos viés na hora de testarMas esse, com certeza,
não
foi meu foco de
Como prática de design
•
É dito que com a prática de TDD, seuprojeto de classes torna-se melhor.
•
Muitos autores (Kent Beck, Martin Fowler,A academia estudou
isso também...
Mas é tão mágico
assim?
•
Em 2010, durante um evento ágil,participantes não souberam bem se
expressar quando o assunto era “como TDD influencia no projeto de classes”.
Aniche, Ferreira, Gerosa. What Concerns Beginner Test-Driven Development Practitioners: A Qualitative Analysis of Opinions in an Agile Conference. 2011
Outras pessoas
já perceberam que
os efeitos de TDD
não são tão naturais
assim!
M. Siniaalto and P. Abrahamsson, “Does test-driven development improve the program code? Alarming results from a comparative case study,” Balancing Agility and
Mas como descobrir?
•
Uma das partes mais desafiadores (elegais!) da ciência é justamente essa: como bolar um experimento controlado que
Um Estudo Qualitativo
Um Estudo Qualitativo
•
~30 desenvolvedores da indústriaUm Estudo Qualitativo
•
~30 desenvolvedores da indústria•
Grande experiência com desenvolvimentode software (só 20% tinham menos de 2 anos de experiência, 30% entre 6 e 10
anos).
Um Estudo Qualitativo
•
~30 desenvolvedores da indústria•
Grande experiência com desenvolvimentode software (só 20% tinham menos de 2 anos de experiência, 30% entre 6 e 10
anos).
•
Praticam TDD há algum tempo (50%pratica entre 1 a 3 anos)
a prática de TDD
não guia o
desenvolvedor para um bom
projeto de classes
de forma
automática!
TDD dá
retorno
constante sobre os possíveis
problemas existentes no atual
projeto de classes. É
tarefa
do desenvolvedor
perceber esses problemas e
melhorar o projeto de acordo.
Regra para a vida!
•
“Se está difícil testar, é porque, provavelmente,há um problema de projeto ou implementação em seu código”.
•
O segredo é perceber, o mais rápidoIsso quer dizer que...
•
A busca pela testabilidade faz com que vocêIsso quer dizer que...
•
A busca pela testabilidade faz com que vocêbusque projetos de classe mais simples
•
instanciar uma classe, e fazer uso deIsso quer dizer que...
•
A busca pela testabilidade faz com que vocêbusque projetos de classe mais simples
•
instanciar uma classe, e fazer uso decomportamentos deve ser fácil
•
classes não podem ser complicadas,Isso quer dizer que...
•
A busca pela testabilidade faz com que vocêbusque projetos de classe mais simples
•
instanciar uma classe, e fazer uso decomportamentos deve ser fácil
•
classes não podem ser complicadas,senão fica difícil testar)
•
Maneira barata de validar seu projeto deQuer ver um exemplo?
•
Um teste sempre tem 3 partes: umcenário, uma ação, e uma validação.
•
Se escrever o cenário para o teste está[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);
[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?
Bloated constructor
[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.. }
dependencies,
notifications,
adjustments
" [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);
}
If’s e switches
Você tem testes muito parecidos que geram resultados
Métodos privados?
•
Devo testá-los?Olhando pros asserts
•
A quantidade de asserts também podeindicar problemas de qualidade no código de produção.
Mas como?
•
Quanto maior a quantidade de “diferentesinstâncias que recebem um assert”, maior a chance do código de produção ter
problemas, em termos de complexidade, linhas de código, número de métodos
invocados.
assertEquals(a.Propriedade, “bla”); assertEquals(b.Propriedade, “ble”);
Padrões de Feedback
Erros comuns
Erros comuns
•
45% dos desenvolvedores disseram queesquecem de refatorar constantemente.
Erros comuns
•
45% dos desenvolvedores disseram queesquecem de refatorar constantemente.
•
40% afirmam que fazem uma refatoraçãoem outro trecho de código durante uma sessão de TDD.
Erros comuns
•
45% dos desenvolvedores disseram queesquecem de refatorar constantemente.
•
40% afirmam que fazem uma refatoraçãoem outro trecho de código durante uma sessão de TDD.
•
20% não começam pelo teste mais simplespossível.
Erros comuns
•
45% dos desenvolvedores disseram queesquecem de refatorar constantemente.
•
40% afirmam que fazem uma refatoraçãoem outro trecho de código durante uma sessão de TDD.
•
20% não começam pelo teste mais simplespossível.
•
35% não fazem baby steps.Baby Steps
•
Na minha opinião, uma das partes mais malBaby Steps
•
Na minha opinião, uma das partes mais malentendidas pela comunidade.
•
Ser simples, não é ser simplório (e nemBaby Steps
•
Não faço baby steps o tempo inteiro; masBaby Steps
•
Não faço baby steps o tempo inteiro; masfico feliz de saber que posso fazer, se precisar.
•
Use sua experiência para decidir em queTDD 100% do tempo?
•
Eu não pratico TDD quando:•
Meu projeto de classes já está bemdefinido.
•
A implementação já está clara na minhacabeça.
Qual a diferença de
escrever o teste antes?
•
Fazendo ou não TDD, eu faço ciclospequenos.
Sou menos produtivo?
•
Se eu escrevo 100 linhas de produção,amanhã escreverei 50 de teste e 50 de produção. Sou menos produtivo?
ATDD
•
A ideia é boa, mas...ATDD
•
A ideia é boa, mas...•
Nunca vi ninguém fazendo.E esse tal de BDD?
E esse tal de BDD?
•
O pensamento BDD me agrada.•
As ferramentas que “implementam” não.Como aprendo TDD?
Como aprendo TDD?
•
Pratique.•
Geralmente são 2 os problemas: aprender aComo aprendo TDD?
•
Pratique.•
Geralmente são 2 os problemas: aprender atestar, e aprender boas práticas de programação (OO, etc).
•
Na hora de aprender a testar, a dificuldadeComo aprendo TDD?
•
Pratique.•
Geralmente são 2 os problemas: aprender atestar, e aprender boas práticas de programação (OO, etc).
•
Na hora de aprender a testar, a dificuldadeé sempre pensar em cenários. Comece rascunhando uma lista.
