TDD: quando e como começar?

[CMilfont]

Caros, qual a dificuldade que vocês estão encontrando para começar a seguir TDD?
Não sabe como começar?
Não sabe quando começar?
Não conhece a teoria suficiente?
Nunca ouviu falar? [nessa lista é dificil essa] :)
...

--
http://www.milfont.org

[Thiago Diogo]

Fala CMilfont, beleza?

To iniciando agora a implantação aqui na empresa e estou com dificuldades em trabalhar com testes que necessitam de uma certa configuração de banco antes de rodarem, por exemplo, tenho um teste que garante que minha camada de serviço não está deixando criar 2 usuários com o mesmo nome, mas para esse teste passar, antes, deve existir um usuário com aquele nome.

To estudando DBUnit e to usando TestNG no projeto, mas essa é a dificuldade até agora. Também estudamos JMock mas ainda não sei como usá-lo.

Estamos comprando uns livros na amazon sobre testes e estou bastante interessado no assunto.

Abraçø

2009/3/31 CMilfont <cmil...@gmail.com>

--
Sds, Thiago Diogo - www.apejava.com.br - A casa do Java!

[Assis Júnior]

Kra, faltou ai colocar: Falta de apoio da gerencia.

2009/3/31 Thiago Diogo <thiag...@gmail.com>:

--
Atenciosamente,
Assis júnior
SCJP 5.0 Certified

[Dieison Rabêlo]

No meu caso, já tentei iniciar, mas tropecei um pouco com o TestNG no JBoss Seam.
É bastante interessante o ponto que o Assis Júnior tocou. Se a adoção de TDD, BDD, métodos ágeis não for top-down, fica muito difícil implantar, e essa dificuldade é maior do que qualquer curva de aprendizado relacionada à tecnologia.

--
Dieison Rabêlo
mail: dieison...@gmail.com
msn: dieison...@msn.com
http://dieisonrabelo.com.br/blog
http://meadiciona.com/dieison

[CMilfont]

Thiago, sobre DBunit, dá uma olhada nesses dois testes se podem te ajudar:

http://code.google.com/p/issuetrackr/source/browse/trunk/issuetrackr/test/org/milfont/model/issuetrackr/integration/LifeCycleOfIssueInProjectIntegrationTest.java

http://code.google.com/p/issuetrackr/source/browse/trunk/issuetrackr/test/org/milfont/model/issuetrackr/integration/ProjectIntegration.java

Eu uso JUnit com JMock, esse link que o Rafael Ponte me passou um
tempo atrás é o melhor material para Jmock e Easymock que conheço
http://jeantessier.com/SoftwareEngineering/Mocking.html

JMock era muito fraco há um tempo atrás, mas agora compete de igual
com os outros, migrei do Easymock para ele estou satisfeito.
Dá uma olhada nesse teste para ver alguns exemplos de uso
http://code.google.com/p/issuetrackr/source/browse/trunk/issuetrackr/test/org/milfont/model/issuetrackr/LifeCycleOfIssueInProjectTest.java

Veja a lista de livros que coloquei o link dentro da página do grupo,
tem alguns sobre teste lá.

2009/3/31 Thiago Diogo <thiag...@gmail.com>:

--
http://www.milfont.org

[CMilfont]

Um livro que trata testes não triviais em frameworks conhecidos é o
Junit Recipes, inclusive tem um capitulo só sobre JEE
http://www.manning.com/rainsberger/

@Assis e @Dieison
Sobre adoção de Agile, vale dar uma ollhada nesse link do Fabricio Lemos:
http://www.fabriciolemos.org/blog/2008/padroes-para-adocao-de-agilidade/

@Dieison
Foi contigo que falei sobre adoção de agile no dia do evento?

2009/3/31 Dieison Rabêlo <dieison...@gmail.com>:

--
http://www.milfont.org

[CMilfont]

Tem esse também
http://www.fabriciolemos.org/blog/2009/openup-como-porta-de-entrada-para-o-mundo-agil/

2009/3/31 CMilfont <cmil...@gmail.com>:

--
http://www.milfont.org

[Aristênio Monteiro Filho]

- Falta de apoio da gerência.
- Muito código legado com falha na arquitetura que deixou mtas regras de negócio em arquivos jsp requisitados via ajax, impossibilitando o uso de JUnit como ferramenta de testes.

2009/3/31 CMilfont <cmil...@gmail.com>

[caike]

Fala Pessoal,

Kra, faltou ai colocar: Falta de apoio da gerencia.

Se a adoção de TDD, BDD, métodos ágeis não for top-down, fica muito difícil implantar, e essa dificuldade é maior do que qualquer curva de aprendizado relacionada à tecnologia.

Eu penso justamente o contrário. Acho que as técnicas de engenharia vêm de baixo pra cima. Você não deve esperar que seu gerente lhe incentive a testar para que você o faça. Provavelmente ele não está preocupado com isso.

Acho que como desenvolvedores somos os responsáveis por tomar a iniciativa de identificar as nossas próprias boas práticas e exercitá-las ao máximo para que fiquem 'no sangue'.

Quando o número de bugs começar a diminuir junto com o tempo para desenvolvimento de novas features, então você vai em frente e fala pra ele que isso é resultado dos seus testes e de tudo de bom que eles trouxeram (baixo acomplamento, alta coesão, etc etc).

Provavelmente ele vai continuar não se preocupando com isso, mas aí a coisa já vai estar dando certo :)

Coisas como reuniões frequentes com o cliente, time-box fixo e outras características mais relacionadas ao processo realmente dependem de um mínimo de esforço de camadas gerenciais. Mas estamos falando de TDD, que não depende de gerente. Depende de cada um!

Quanto a mocking, conhecem o Mockito ?

Abraço!

2009/3/31 Aristênio Monteiro Filho <aris...@gmail.com>

--
Att,
- Caike
www.caikesouza.com

[Assis Júnior]

@Milfon ja conhecia o link. Só citei pq achei um ponto interessante em se tocar.

@Caike Existem gerentes que claramente e explicitamente falam para
testar o mínimo necessário. Estes mesmos tipos de gerente tmbm acham
que testes automatizados são uma grande perda de tempo.

2009/3/31 caike <carlos...@gmail.com>:

[caike]

Assis,

Aí o problema seria a forma "command and control" de gerência.

Mas se você como desenvolvedor reconhece o valor das boas práticas e já possui sua maneira de utilizá-las a ponto de gerar resultados satisfatórios, não tem como o gerente não enxergar isto!

Aproveitei o embalo para o post:

http://www.caikesouza.com/blog/2009/03/tdd-just-do-it/

Abraço!

2009/3/31 Assis Júnior <assi...@gmail.com>

[Dieison Rabêlo]

@Caike, quando digo top-down, falo no sentido do apoio, no sentido de dar valor às práticas propostas pelos desenvolvedores.

@Milfont, sim, conversamos e te falei sobre minha dificuldade em testar no Seam, se seriam testes unitários ou de integração etc...

[Assis Júnior]

@Caike, cara algumas vezes não é tam simples assim... Quando a equipe
é grande, prazos já extrapolados e os 'superiores' tem preconceito com
agile e tecnicas sucesso (com agile) é visto como sorte. Quando o cara
diz que so teste o minimo e não possui mente mais aberta, oq fazer?

2009/3/31 caike <carlos...@gmail.com>:

[caike]

Fala Assis,

Mas aí vem a grande questão, que remete ao outro tópico em andamento sobre o post do Akita (NNPP): as outras pessoas da equipe admitem que precisam melhorar ? Caso admitam, elas realmente querem melhorar ?

As vezes, por motivos pessoais, sociais ou por pura comodidade elas preferem que as coisas continuem do jeito que estão. Prazos atrasados não são novidade. Software, de uma forma ou de outra, falha há 30 anos e nunca ninguem se surpreendeu com isso.

Não adianta dar murro em ponta de faca.

[Fabricio Lemos]

Assis, você já tentou automatizar os testes funcionais? As vezes é mais vantajoso começar com testes funcionais para aplicação que já são problemáticas.

2009/3/31 Assis Júnior <assi...@gmail.com>

--
Fabrício Lemos
http://www.fabriciolemos.org/

[Assis Júnior]

Olá Fabrício,

O problema não é tecnica. Os superiores realmente não querem 'perder
tempo' com testes automatizados. Já ouvi em reuniões algo do tipo 'se
funcionou uma vez não meche mais esquece...'

Bem, fora o emprego normal possuo mais 3 projetos:

1. Proj. de manutenção em struts com jsp e js. Não possui testes
herdei ele já assim, mas ele é bem simples. as 3 funcionalidades que
eu incluí possuem testes unitários.

2. Projeto em dotnet para sistema de vendas: Inicio como 'spike
solution' em seguida com testes unitários. Algumas dificuldades para
usar mock.

3. Proj. movel em dotnet: vou iniciar com os testes nele.

4. Proj movel em java quando o projeto iniciar será tdd após o
prototipo inicial, assim como os outros em dotnet.

Inicialmente faço um prototipo bem simples sem framework nenhum so pra
ver a ideia depois inicio com os testes e sigo no tdd.

2009/3/31 Fabricio Lemos <fabrici...@gmail.com>:

[Fabricio Lemos]

Disse isso não pela técnica, mas porque as vezes testes funcionais tem um visibilidade maior. Fica mais fácil para quem não entende nada ver algum benefício.

Mas se a gerência é tapada até o ponto de fazer comentários como os que você citou, ou a equipe perdeu toda a confiança do gerente, ou é um gerente MUITO ruim. Seja qual for o motivo, acho que um problema desses só se resolve com realocação de pessoas: ou sai o gerente ou o líder técnico da equipe.

2009/3/31 Assis Júnior <assi...@gmail.com>

[CMilfont]

Caike publicou em seu blog sobre essa thread
http://www.caikesouza.com/blog/2009/03/tdd-just-do-it/

Acho excelente levarmos a discussão para fora da lista e eu mesmo faço
- e farei nessa thread em particular, estou deixando ter mais volume
para sintetizar - mas quando publicarem, postem aqui para mantermos
histórico de tudo ;)

2009/3/31 CMilfont <cmil...@gmail.com>:

--
http://www.milfont.org

[Clavius Tales (Fortes Informática)]

Oi, Assis.

2009/3/31 Assis Júnior <assi...@gmail.com>

@Caike, cara algumas vezes não é tam simples assim... Quando a equipe
é grande, prazos já extrapolados e os 'superiores' tem preconceito com
agile e tecnicas sucesso (com agile) é visto como sorte. Quando o cara
diz que so teste o minimo e não possui mente mais aberta, oq fazer?

Convencê-lo de que isso é burrice.

 

Um abraço.

 

Tales

[Clavius Tales (Fortes Informática)]

Oi, Assis.

Atividade semanal para você: catalogue todos os erros que testes
automatizados evitariam. Catalogue ainda o percentual do tempo que a equipe
perde corrigindo esses erros. Com esses dados, chegue para seu gerente e
mostre o que ele ganharia se tivesse testes automatizados. Lembre-se também
de falar da imagem negativa que esses erros causam no cliente.

Agora um problema: se a equipe não tem testes automatizados no sangue, fazer
tudo de uma vez vai jogar a produtividade lá para baixo. É fundamental que
as pessoas estejam capacitadas. Se você acha complicado convencer toda a
equipe a se capacitar, capacite-se pelo menos. Fora do expediente,
desenvolva projetos particulares e pratique testes exaustivamente, até virar
craque. Quando isso acontecer, insira essas técnicas no seu prórprio
processo de desenvolvimento no trabalho. Com o tempo, os resultados virão. E
aí o gerente e a equipe se convencerão de que testes automatizados são uma
boa.

Um abraço.

Tales

P.S.: outra dica: foque em apenas um desses projetos paralelos. Esqueça os
demais.

--------------------------------------------------------------------------------




Verificado por AVG - www.avgbrasil.com.br
Versão: 8.0.238 / Banco de dados de vírus: 270.11.34/2032 - Data de
Lançamento: 03/31/09 06:02:00

[Matheus Fechine]

É exatamente o que está acontecendo no cliente em que estou alocado. Os testes automatizados vão ser a salvação do produto final. A cada ISSUE que pegamos, só liberamos quando o teste estiver implementado (e funcionando, é claro :)).

2009/3/31 Clavius Tales (Fortes Informática) <ta...@grupofortes.com.br>

[Assis Júnior]

@Clavius Estou conseguindo conciliar os projetos. Isso não é um
problema ainda porque os prazos são razoaveis.

2 de dotnet são para a pós-graduação o de manutenção é simples e não é
sempre que tem alterações (lucro bom tmbm).

Já tenho uma agenda de dedicação a cada um desses projetos.

Valeu pelos conselhos.

2009/3/31 Clavius Tales (Fortes Informática) <ta...@grupofortes.com.br>:

[Clavius Tales (Fortes Informática)]

Se dão dinheiro, mantenha. Pensei que era só para aprendizado.

Versão: 8.0.238 / Banco de dados de vírus: 270.11.35/2034 - Data de
Lançamento: 04/01/09 06:06:00

[Assis Júnior]

1. Eles já estão incorporados em minha agenda e ja sei meu limite para
aceitar projetos. Terceirizo detalhes como design, relatórios e coisas
que ocupam grande tempo, consego controlar isso pq normalmente os
prazos são razoaveis.

2. A vida é um constante aprendizado. O projeto para dot net estou
aprendendo com ele pois não tenho larga experiencia em dotnet. Estou
querendo concluir um projeto que já está quase pronto para poder
aceitar uma proposta de um outro projeto já esse mes. Então vou usar o
seam (Esse projeto é bem simples, 1 cadastro e 4 relatórios, então é
minimizados os riscos de uma tecnologia nova) já aprendendo à usá-lo.

2009/4/1 Clavius Tales (Fortes Informática) <ta...@grupofortes.com.br>: