Olá bom dia,
TDD em equipes pequenas é essencial? Trabalho com uma equipe de 6 desenvolvedores e 2 analistas, ninguem é dedicado totalmente a testes, estamos buscando formas de surprir essa lacuna, e uma das sugestoes é TDD, oq vcs acham? tem alguma outra sugestao?
OBS:trabalhamos com SCRUM
Me diga uma coisa por que alguem dedicado para os testes?
Quem programa pode muito bem escrever os testes sem problema algum.
Testes automatizados são muito importantes para manter a integridade do sistema, ou quem nunca viu o mechi aqui deu problema lá…
[quote=Crown]Olá bom dia,
TDD em equipes pequenas é essencial? Trabalho com uma equipe de 6 desenvolvedores e 2 analistas, ninguem é dedicado totalmente a testes, estamos buscando formas de surprir essa lacuna, e uma das sugestoes é TDD, oq vcs acham? tem alguma outra sugestao?
OBS:trabalhamos com SCRUM[/quote]
O tamanho da equipe não faz diferença para o uso de práticas como TDD. TDD vai te ajudar no design do seu código e na testabilidade também.
[]s
[quote=Crown]Olá bom dia,
TDD em equipes pequenas é essencial? Trabalho com uma equipe de 6 desenvolvedores e 2 analistas, ninguem é dedicado totalmente a testes, estamos buscando formas de surprir essa lacuna, e uma das sugestoes é TDD, oq vcs acham? tem alguma outra sugestao?
[/quote]
ainda bem que ninguem é dedicado a testes (em scrum todos têm que fazer tudo), mas se ninguem sabe fazer testes TDD pode ser overkill.
Além de que TDD não te dá necessariamente uma boa modelagem.
Se usam scrum, a vossa definição de pronto deve conter a existencia de testes, mesmo que sejam de aceitação. Não ha requisito no scrum de que as coisas sejam automáticas. Automatizar é um artificio para ganhar velocidade.
numa primeira aproximação TDD é demasiado exigente para quem começa, vc pode simplesmente adotar que irá criar testes conforme as estorias pedirem. Por exemplo, uma estoria que pode ser demonstrada não pela tela ou uso do sistema mas por dar verde no junit. Isso parece um teste, é um teste de aceitação, mas entra no esquema das coisas como uma forma de demonstração de pronto.
Para classes que tomam decisões de negocios, é bom fazer testes unitários.
Para classes de infra, testes integrados.
Para as estorias, testes de aceitação (que ñ precisam ser automáticos, mas é conveniente que sejam)
Automatizar os testes não é trivial. A sua apliacação, o seu modelo , o seu design e a sua infra têm que permitir isso. Vc tem que ter um elevado grau de desacoplamento e obter isso não é trivial. Fazer testes automáticos obrigam-no a pensar duas vezes antes de dar um “new” e se vc não usa algum sistema de injeção é puro suicidio.
Como ainda nao me dediquei totalmente ao assunto posso estar falando besteira: Em metodologias ageis aquela velha historia dq “o desenvovedor nao pode testar o seu proprio codigo” vira mito? pois tdd te da uma visao de cima da funcionalidade te deixando apto a desenvolver os testes?
ps:Sou novo em metodos(ou metodologias) ageis, e nao tive tempo ainda de entrar mais afundo pois vou ter prova de certificacao terça, e meu tempo livre tenho me dedicado a ela por enquanto =p.
TDD te traz beneficios. Experimente primeiro fazer no seu modelo, vai te poupar boas horas de teste no futuro.
Programadores serios testam. E testam muito, todo o tipo de teste. Se não existe ferramenta temos que criar nós mesmos. É o preço da qualidade.
[quote=peczenyj]TDD te traz beneficios. Experimente primeiro fazer no seu modelo, vai te poupar boas horas de teste no futuro.
Programadores serios testam. E testam muito, todo o tipo de teste. Se não existe ferramenta temos que criar nós mesmos. É o preço da qualidade.[/quote]
Concordo, mas existe a teoria do teste viciado e dq quem implementou nao pode testar…era isso que eu estava me referindo. Talvez tenha me expressado mal.
[quote=Crown]Como ainda nao me dediquei totalmente ao assunto posso estar falando besteira: Em metodologias ageis aquela velha historia dq “o desenvovedor nao pode testar o seu proprio codigo” vira mito?
[/quote]
Mais ou menos.
Em agil, o codigo é de todos. Então que vc cria uma classe e cria o teste para ela, vc não está criando o teste para a “sua” classe.
Porque a classe não é sua e o teste não é seu, qq outro pode a qualquer momento incrementar qq um dos dois. E todos são responsáveis por deixar todos os testes verdes.
O conceito de que o codigo não é de quem o escreveu e sim de toda a equipa, passada e futura estabelece um novo paradigma onde essa historia não se aplica.
TDD não trata de escrever código que verifica se outro codigo funciona. Isso seriam testes unitários, integração, etc…
TDD trata de vc escrever exemplos executáveis das features do seu sistema. usa-se um framework de testes porque é prático mas o conceito é diferente. Quando vc usa TDD vc cria um monte de classes junit. Isto não significa que o seu codigo está testado porque o TDD só evolui até ao ponto em que funciona. Não existe no TDD a clausula que diz “Se está funcionando adicione outro teste até que quebre”.
O TDD funciona num ciclo fechado e limitativo. É por isto que TDD não permite que vc alcance um modelo robusto e flexivel a menos que vc crie testes que são muito mais genericos que necessário ( o que viola uma das direcivas do TDD).
É preciso diferenciar TDD daquilo que se faz em XP, por exemplo, chamado Test First. O Test First é a primeira diretiva do TDD, mas é nas segunda e terceira que está implicita um mecanismo de limitação que não existe em XP, por exemplo.
TDD não é sobre desenvolver testes, é sobre desenvolver a aplicação usando pequenos mini-programas que são executados na forma de testes.
Entendi(pelo menos o conceito), ja deu para ter uma ideia dq que se trata TDD, agora vou aprofundar. Obrigado a todos.