Testes: ponto fraco na comunidade Django
Luciano Ramalho
coisa boa os colegas da lista já colocaram no ar.
Mas se tem uma área em que a gente coletivamente perde pro pessoal de
Ruby on Rails é no uso de testes automatizados.
Pela minha experiência pessoal, conversando com muitos praticantes de
Django no mercado brasileiro eu noto que apenas uma pequena minoria
tem o hábito de fazer testes automatizados com cobertura significativa
em seus projetos. Eu adoraria que me provassem estar errado...
Pois bem, temos uma chance de ouro de reverter isso: na Trilha Python
do evento TDC2010 teremos duas palestras de caras muito experientes de
Ruby e Python falando sobre testes automatizados com Python:
- o Adriano Petrich, que foi meu colega no BSGI, vai falar sobre
técnicas específicas de testes com Django
- o Bernardo Heynemann (Globo.com) e o Guilherme Chapiewsky (Yahoo!)
vão falar sobre o PyCcuracy, sistema de testes de aceitação para
qualquer tipo de aplicação Web
Vamos lá, pessoal, custa apenas R$ 20 a inscrição em cada trilha do
TDC. Só vinte pela Trilha Python, é isso aí, nada mais!
Precisamos mostrar pros colegas da comunidade Ruby que a gente também
lota eventos com antecedência!
Mais informações e inscrições:
http://www.thedevelopersconference.com.br/
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Rodrigo Pinheiro Matias
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
--
Rodrigo Pinheiro Matias
Bacharel em Ciência da Computação
Celular
+55 (063) 8111.2080
Telefone em horário Comercial
+55 (063) 3216.7564
Blog
http://rodrigomatias.goware.com.br/blog/
Feed
http://rodrigomatias.goware.com.br/blog/feed/
http://twitter.com/rodrigopmatias
Luciano Ramalho
> Construtivo o mercham, não sei se porque é um assunto que quero me
> aperfeiçoar, mas gostei, uma pena que não poderei ir no evento.
Legal, Rodrigo, grato pelo seu interesse.
Eu também acho o tema muito importante, mas não é fácil dar os
primeiros passos nos testes automatizados. Na verdade os primeiros até
são fáceis. Os segundos e terceiros é onde a gente tropeça e muitas
vezes desiste.
Só para deixar claro para todos, não estou sendo remunerado pela
organização do TDC de nenhuma maneira.
Ajudei a organizar a Trilha Python para a Associação Python Brasil em
benefício da nossa comunidade, voluntariamente, da mesma forma que é
voluntário o trabalho de todos os diretores e conselheiros da APyB,
moderadores de listas e organizadores de grupos regionais.
Diego Manenti Martins
> Eu também acho o tema muito importante, mas não é fácil dar os
> primeiros passos nos testes automatizados. Na verdade os primeiros até
> são fáceis. Os segundos e terceiros é onde a gente tropeça e muitas
> vezes desiste.
Isso mesmo. A documentação que vi até agora sobre o assunto até
explica bem como fazer testes.
A minha dificuldade maior está em saber *o que testar* e *que tipo de
teste* fazer.
Alguma documentação sobre isso?
--
diego
Felipe Djinn Asmodeu
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
Tarsis Azevedo
Tarsis Figueredo Azevedo.
-------------------
Linux User: #496982
-------------------
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-Martin Fowler, Refactoring: Improving the Design of Existing Code"
Felipe Prenholato
Linux User nº 405489
Home page: http://chronosbox.org/blog
Twitter: http://twitter.com/chronossc
Felipe Djinn Asmodeu
Luiz Carlos Santos
Luiz Carlos
Mário Neto
Galera, este evento vai ser gravado ou transmitindo ?
Luiz Carlos
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
--
Att. Mário A. Chaves Neto
Designer / U.I. Engineer
MBA - Design Digital
Osvaldo Santana
Esta é uma grande dúvida minha também...rsrsr
--
Osvaldo Santana Neto — Triveos Tecnologia
Phone: +55 41 9244-1646
Felipe Djinn Asmodeu
--Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
Gileno Alves
Gileno Filho
Tarsis Azevedo
-------------------
Linux User: #496982
-------------------
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-Martin Fowler, Refactoring: Improving the Design of Existing Code"
Renne Rocha
Marinho Brandao
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
tiagoprn
TIAGOPRN
Desenvolvedor Web, Linux e Windows
(Django, Python, Delphi, Lazarus, MySQL, SQLite)
E-mail: tiag...@gmail.com
Blog: http://tgplima.net84.net
LinkedIn (profile público): http://br.linkedin.com/in/tiagoparanhoslima
twitter: https://twitter.com/tiagoprn
Gerson Minichiello
por um preço desses com toda essa qualidade não tem como deixar de
participar :)
Iuri
Andrews Medina
primeiramente, parabéns pela iniciativa da palestra sobre testes,
concordo com Ramalho que nós da comunidade python e django falamos e
praticamos pouco no que se trata de testes, tdd, bdd.
2010/8/10 Marinho Brandao <mar...@marinhobrandao.com>:
> O maior problema em implementar testes TDD/BDD no Django não está nos
> recursos disponíveis e sim em escrever testes (e seguir praticando, não
> importa qual pressão esteja sendo exercida). Eu uso bastante testes,
> confesso que muito abaixo do que eu gostaria, mas de uma forma geral, sei
> que estão à altura da realidade.
Concordo que o problema não está nos recursos, até porque, hoje em dia
existem muitos recursos para auxiliar nos auxiliam no desenvolvimento
de testes como ci's (integracao continua), mocks, runners, ferramentas
para fixtures, coverage e etc.
Mas nao concordo em me conformar com a altura da realidade.
Escrever testes para quem não está acostumado no inicio pode parecer
incoerente, chato e lento. Mas isto deve ser uma disciplina, uma
filosofia e uma realidade de qualquer desenvolvedor que se diz 'agil'.
IMHO testar de forma automatizada é muito mais barato e prazeroso que
'debugar', e conforme a quantidade de features vai aumentando, os
testes vao mantendo a confiança do código, garantindo que
features/codigos antigos não quebrem sem que os testes 'avisem'.
E fazer TDD para mim é voce saber o que espera de uma feature ou
codigo que é expressado pelo teste, e depois voce implemente um código
que faça esse teste passar, provando que ele esta agindo conforme o
esperado. Ou seja, para chegar a algum lugar voce precisa saber aonde
quer ir e o TDD é isso expressado em código.
Atualmente eu estou em um projeto grande que tem várias pessoas
trabalhando nele, e praticamente utilizando apenas o unittest e o test
client do Django temos uma cobertura de 95% do código testado. (isso
não é motivo de orgulho porque, ainda há 5% do código que pode ter
comportamentos que eu nao posso prever de forma automatizada).
Temos tambem testes para javascript com qunit, testes de aceitacao com
pyccuracy (mas vou falar dele daqui a pouco).
> O Django/Python tem sim alguma carência nesse assunto, como por exemplo um
> código coerente pra dar uma noção real da cobertura de testes. Também falta
> um bom investimento no suporte a doctests. Mas o TDD/BDD não vivem só de
> recursos ou sozinhos. Tem integração contínua, implementação de aplicações
> plugáveis, o uso adequado de zc.buildout/virtualenv/fabric, enfim... tem
> muitos recursos que podem ser usados juntos pra fazer o testes automatizados
> que realmente ajudem.
Eu acho que a carencia nao esta no Django e nem no Python mas sim em
sua comunidade, ou seja, nós. Como falei, existem várias ferramentas
para CI, mock e etc. Mas é dificil achar 'guias' de como testar uma
aplicação web por exemplo. Poucos projetos opensource em django são
testados e acredito que poucos projetos em django privatos tambem sao
testados.
Testar aplicaçoes em Django não é doloroso, pelo contrário, pode ser
bem fácil e divertido, basta a gente começar.
Esse evento é uma iniciativa de mostrar para o mundo (que ha testes em
Python) e algumas formas de testar em Python. Mas acho que podemos
fazer mais.
Escrever codigos com teste, blogar sobre isso, falar na lista,
submeter treinamentos e palestras sobre isso na PythonBrasil e outros
eventos é uma forma de fazer isso.
Quero ver se dedico um pouco do meu tempo para blogar e escrever sobre
o assunto tambem.
ps: Quanto ao pyccuracy, ele tem como objetivo automatizar ações (e
tambem testar) no browser a partir de uma linguagem natural, para
simular 'historias'/features a partir da visao do cliente/PO/analista
de produto e ele o faz bem, e não facilitar os testes em Django.
Valeu,
--
Andrews Medina
www.andrewsmedina.com
Marinho Brandao
Alguns aqui devem conhecer a definição de "Indústria de Ponta" e "Indústria de Massa". A primeira prioriza a qualidade, a segunda prioriza o custo. Há espaço para ambas no mercado.
Quando você compra um parafuso na ferragista, você paga um preço X. Se o mesmo parafuso for fabricado para a NASA, haverá toda uma produção otimizada e qualificada para produzir o mesmo parafuso com material e precisão ideais para atender à exigência, então o custo dele será muito maior. A indústria de ponta tem um mercado muito reduzido, que precisa de resolução (precisão) e paga o preço por isso. A indústria de massa atende a um mercado muito maior, porém com necessidades mais genéricas e custos mais baixos.
Testes é só mais uma ferramenta da produção. Se o projeto é de ponta, exige cobertura alta, se é de massa, pode ficar com uma cobertura menor. E cada caso é um caso.
É bobagem tentar levar a coisa pro lado de que, se não tiver cobertura perfeita, não serve. É desconhecimento sobre a lógica do Mercado e do capitalismo.
Na verdade, temos tido ótimos resultados onde temos aplicado TDD. Onde não aplicamos, no longo prazo o resultado não é bom. Alguns projetos justificam, outros não.
Andrews,
a equipe da Globo é um exemplo pra nós nesse tópico :)
O django-test-coverage diz um percentual de cobertura que não é real. Os algorítimos de cobertura geralmente não consideram complexidade ciclométrica, Big-O, variações de deploy e situações críticas, etc... então eu já acho 70% bem alto e fico impressionado que tenham atingido a marca dos 95% :D
No nosso caso, temos uma cobertura boa e deploy também organizado. O nosso grande desafio agora é implementar testes de navegador (em geral), e também montar uma boa Integração Contínua. Mas eu nunca estou satisfeito e sempre acho que poderia fazer mais... rs
Mas é isso aí, boa noite pra vocês :D
Andrews Medina
2010/8/12 Marinho Brandao <mar...@marinhobrandao.com>:
> Testes é só mais uma ferramenta da produção. Se o projeto é de ponta, exige cobertura alta, se é de massa, pode ficar com uma cobertura menor. E cada caso é um caso.
>
Eu não concordo que testes seja mais uma ferramenta e sim uma forma
diferente de desenvolver software. Mas não sei se cabe a esse email
essa discussão.
>
> a equipe da Globo é um exemplo pra nós nesse tópico :)
>
obrigado =)
> No nosso caso, temos uma cobertura boa e deploy também organizado. O nosso grande desafio agora é implementar testes de navegador (em geral), e também montar uma boa Integração Contínua. Mas eu nunca estou satisfeito e sempre acho que poderia fazer mais... rs
>
Quanto a CI existe um feito em Python pelo meu amigo Bernado, que é o
skink (http://github.com/heynemann/skink) que é bem simples de
instalar e configurar.
Mas atualmente tenho utilizado o TeamCity (http://www.jetbrains.com/teamcity/).
QUanto a testes de navegador recomendo dar uma olhada no selenium2 ele
corrige varias coisas pendentes no selenium atual e é bem promissor.
[]'s
--
Andrews Medina
www.andrewsmedina.com
Marinho Brandao
> Eu não concordo que testes seja mais uma ferramenta e sim uma forma
> diferente de desenvolver software. Mas não sei se cabe a esse email
> essa discussão.
Claro, mas lembre-se: estamos falando o tempo todo de dinheiro, mercado, soluções, clientes, etc... se for pra brincar, podemos brincar de qualquer coisa, mas se for pra dar resultado, tem que pensar fora da área técnica e ter uma visão do processo. E na visão do processo, TDD é ferramenta, assim como orientação a objetos e Django também são.
Ferramentas, você descarta ou usa em dosagem diferente quando achar que deve.
Usando um exemplo mais prático: Ferrari é perfeita, então só porque a Ferrari é perfeita, um Gol é lixo? Não, simplesmente atendem a segmentos diferentes, com exigências diferentes (e pagamento também), portanto aplicam conceitos em dosagens diferentes, e materiais diferentes.
Software é a mesma coisa ;)
> Quanto a CI existe um feito em Python pelo meu amigo Bernado, que é o
> skink (http://github.com/heynemann/skink) que é bem simples de
> instalar e configurar.
Eu tenho gostado do buildbot :) Mas vou conhecer esse aí
> Mas atualmente tenho utilizado o TeamCity (http://www.jetbrains.com/teamcity/).
Já ouvi falar
> QUanto a testes de navegador recomendo dar uma olhada no selenium2 ele
> corrige varias coisas pendentes no selenium atual e é bem promissor.
Pois é... o maldito Selenium... rs... mas enfim, parece que é a única opção, então é nele que eu tenho apostado também.
Abraço e boa noite!
ig...@igorsobreira.com
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
ig...@igorsobreira.com
Olá Andrews :)
Claro, mas lembre-se: estamos falando o tempo todo de dinheiro, mercado, soluções, clientes, etc... se for pra brincar, podemos brincar de qualquer coisa, mas se for pra dar resultado, tem que pensar fora da área técnica e ter uma visão do processo. E na visão do processo, TDD é ferramenta, assim como orientação a objetos e Django também são.
> Eu não concordo que testes seja mais uma ferramenta e sim uma forma
> diferente de desenvolver software. Mas não sei se cabe a esse email
> essa discussão.
Ferramentas, você descarta ou usa em dosagem diferente quando achar que deve.
Usando um exemplo mais prático: Ferrari é perfeita, então só porque a Ferrari é perfeita, um Gol é lixo? Não, simplesmente atendem a segmentos diferentes, com exigências diferentes (e pagamento também), portanto aplicam conceitos em dosagens diferentes, e materiais diferentes.
Software é a mesma coisa ;)
Eu tenho gostado do buildbot :) Mas vou conhecer esse aí
> Quanto a CI existe um feito em Python pelo meu amigo Bernado, que é o
> skink (http://github.com/heynemann/skink) que é bem simples de
> instalar e configurar.
Já ouvi falar
Pois é... o maldito Selenium... rs... mas enfim, parece que é a única opção, então é nele que eu tenho apostado também.
> QUanto a testes de navegador recomendo dar uma olhada no selenium2 ele
> corrige varias coisas pendentes no selenium atual e é bem promissor.
Abraço e boa noite!
----
Marinho Brandão (José Mário)
http://www.marinhobrandao.com/
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
--
Igor Sobreira
www.igorsobreira.com
Luciano Ramalho
2010/8/11 Andrews Medina <andrew...@gmail.com>:
> Concordo que o problema não está nos recursos, até porque, hoje em dia
> existem muitos recursos para auxiliar nos auxiliam no desenvolvimento
> de testes como ci's (integracao continua), mocks, runners, ferramentas
> para fixtures, coverage e etc.
>
> Mas nao concordo em me conformar com a altura da realidade.
Eu também não, por isso lancei esta discussão aqui na lista com um
assunto desafiador. E fiquei muito feliz em ver que duas propostas de
palestra para a nossa trilha no TDC eram sobre testes.
> Escrever testes para quem não está acostumado no inicio pode parecer
> incoerente, chato e lento. Mas isto deve ser uma disciplina, uma
> filosofia e uma realidade de qualquer desenvolvedor que se diz 'agil'.
>
> IMHO testar de forma automatizada é muito mais barato e prazeroso que
> 'debugar', e conforme a quantidade de features vai aumentando, os
> testes vao mantendo a confiança do código, garantindo que
> features/codigos antigos não quebrem sem que os testes 'avisem'.
Concordo totalmente. O problema para quem está começando é que os
primeiros testes até são fáceis, mas trabalhosos porque ainda não se
tem a prática. Só que logo logo pintam aquelas coisas que não são
fáceis mesmo de testar, e como não se tem as manhas nem as ferramentas
adequadas (como fazer um mock? usar uma lib? qual? fazer em casa?
como?), a tentação de desistir se torna muitas vezes irresistível.
É o tipo de habilidade em que a melhor forma de se desenvolver é estar
inserido em um time onde uns ajudam os outros, alguns caçam
ferramentas, outros constroem, os menos experientes têm a quem
recorrer quando empacam... o tipo de ambiente que vocês têm na
Globo.com, mas não é qualquer empresa que tem dezenas de programadores
escolados em técnicas ágeis. Na verdade, eu não conheço nenhuma outra
no Brasil.
É aqui que eu gostaria de dar uma contribuição: lá onde eu trabalho
estamos desenvolvendo um software em Django chamado OpenTrials [1].
[1] http://reddes.bvsalud.org/projects/clinical-trials/
O OpenTrials é Open Source (LGPL) e tem uma missão humanitária muito
importante: servir de base para sites como o Registro Brasileiro de
Ensaios Clinicos [2] e outros sites semelhantes em outros países.
[2] http://ecgovbr.bvsalud.org/
O objetivo do EC.gov.br (o domínio vai ficar assim) é dar
transparência aos testes de medicamentos com seres humanos para que o
governo e a sociedade civil possam monitorar estes testes, e para que
os testes que não apresentam o resultado esperado também sejam
conhecidos (o que não acontece hoje, em virtude da tendência de só se
publicar o que dá certo).
Então o OpenTrials é o "motor" do Ec.gov.br assim como o MediaWiki é o
motor da Wikipedia.
Pois bem, nós gostaríamos muito de ter testes automatizados no
OpenTrials, mas não temos.
Que tal se a gente fizesse um mutirão/sprint na área aberta do TDC, no
sábado dia 21, para implementar testes no OpenTrials? Eu sugeri isso
para o Adriano Petrich, que vai falar sobre TDD em Django, e ele
topou. Então pelo menos um guru de testes nós teremos, quem sabe mais.
Eu com certeza estarei lá também, participandlo desse sprint.
Ao participar do sprint cada um ganharia mais experiência com testes
no Django, a comunidade como um todo ganharia exemplos de testes em um
aplicativo Open Source, e a sociedade civil do Brasil e de outros
países ganhariam uma plataforma melhor para monitorar os ensaios
clínicos.
E então, quem se interessaria em participar? Precisa estar disponível
sábado, dia 21, e a fim de ir ao TDC. Não precisa se inscrever em
nenhuma trilha do sábado. Basta se inscrever em qualquer trilha (ex.
Python ;-), para ter acesso às áreas de atividades livres do TDC.
[ ]s
Luciano
>
> Testar aplicaçoes em Django não é doloroso, pelo contrário, pode ser
> bem fácil e divertido, basta a gente começar.
>
> Esse evento é uma iniciativa de mostrar para o mundo (que ha testes em
> Python) e algumas formas de testar em Python. Mas acho que podemos
> fazer mais.
>
> Escrever codigos com teste, blogar sobre isso, falar na lista,
> submeter treinamentos e palestras sobre isso na PythonBrasil e outros
> eventos é uma forma de fazer isso.
>
> Quero ver se dedico um pouco do meu tempo para blogar e escrever sobre
> o assunto tambem.
>
> ps: Quanto ao pyccuracy, ele tem como objetivo automatizar ações (e
> tambem testar) no browser a partir de uma linguagem natural, para
> simular 'historias'/features a partir da visao do cliente/PO/analista
> de produto e ele o faz bem, e não facilitar os testes em Django.
>
> Valeu,
>
> --
> Andrews Medina
> www.andrewsmedina.com
>
> --
> Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
> Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
--
Marinho Brandao
Discordo. Django é uma ferramente, TDD é uma prática, uma maneira de desenvolver. Tem gente que antes de escrever um método escreve o que ele vai fazer, como uma docstring. Isso também é uma boa prática.Você usa ferramentas para fazer TDD (como o unittest, nose, etc).
Ramiro B. da Luz
2010/8/12 Marinho Brandao <mar...@marinhobrandao.com>:
Bom, muitas coisas foram faladas, não vai dar para comentar por tópicos.
Eu assisti esse vídeo[1] e achei muito legal mesmo a abordagem. Fala
sobre ruby, mas
o importante é o assunto TDD, metodologia de ensino e custos. Gostaria
apenas de comentar
um ponto relacionado a custos. Usar a metodologia TDD baixa custos de
produção de software.
Independente da ferramenta usada para TDD ou da linguagem, a agilidade
está na confiança e
na possibilidade de incluir features e refatorar. Assistam, vale a pena.
[1] - http://expressocapital.blogspot.com/2010/07/test-fisrst-teaching.html
--
--
-- Ramiro Batista da Luz
-- rami...@gmail.com
-- (41) 9173-2231
-- http://www.ramiroluz.eti.br
-- Programador || Câmara Municipal de Curitiba
ig...@igorsobreira.com
Opa :)Discordo. Django é uma ferramente, TDD é uma prática, uma maneira de desenvolver. Tem gente que antes de escrever um método escreve o que ele vai fazer, como uma docstring. Isso também é uma boa prática.Você usa ferramentas para fazer TDD (como o unittest, nose, etc).De acordo com a Wikipedia [1]:"(Ferramenta) É um utensílio, dispositivo, ou mecanismo físico ou INTELECTUAL utilizado por trabalhadores das mais diversas áreas para realizar alguma tarefa....Em função do disposto acima, uma ferramenta pode ser definida como: um dispositivo que forneça uma vantagem mecânica ou MENTAL para facilitar a realização de tarefas diversas."
Como estamos falando do processo em si, existem diversas "ferramentas" para se aplicar, como TDD, BDD, DDD, RUP, CI e por aí vai... :)
Mas se estivéssemos falando de todo o conjunto, incluindo os softwares usados, eu também chamaria TDD de uma prática de metodologias ágeis ou algo próximo disso :D
Agora veja bem: eu sou tão entusiasta de TDD quanto vocês. Aplico TDD desde 2004. No ERP temos 23 aplicações, das quais umas 20 possuem testes razoáveis de modelo, API, mudanças de estado e troca de mensagens (messages queueing). Os melhores trabalhos que já fiz foram os que eu apliquei testes e o resultado é claramente vinculado à cobertura. Não há dúvidas quanto à importância dos testes.Mas nem todo projeto justifica a escrita prévia de testes. E a maioria dos desenvolvedores não têm preparo pra escrever testes. É um conceito que depende de qualificação específica pra isso, e inclui outras áreas de conhecimento (análise e arquitetura, por exemplo).
Na imensa maioria, os projetos são pequenos e mantidos por equipes pequenas e heterogêneas, com recursos financeiros e de prazo reduzidos. Então a pergunta é: "quanto da TDD é aplicável?"E a resposta NÃO é "tudo", nem "100% de cobertura". A resposta é "depende". Porque depende do resultado que se espera.
Lembrando o caso da Ferrari: a fabricação de uma é feita no limite do conhecimento da indústria. Se você me perguntar se uma Ferrari é melhor do que um carro popular, é óbvio que a resposta será sim. Mas o mercado não tem condições de pagar o preço, compreende? Se toda a indústria automobilística dissesse "nós só vamos produzir carros no máximo da qualidade", raríssimas pessoas teriam carros, porque seria muito caro.
O mesmo vale para o software.Ou seja: primeiro é preciso aprender a trabalhar com testes, depois é preciso planejar a qual profundidade se deseja aplicá-los. E isso tem que estar dentro do orçamento e ao alcance da equipe.É isso que eu estou falando :)
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
--
Igor Sobreira
www.igorsobreira.com
Marinho Brandao
bom, eu acho que já falei bastante, e não pretendo (nem posso) seguir escrevendo desse tanto... rs... então vou tentar esgotar aqui o que eu tenho a dizer.
Ramiro, não vi o video, mas vou ver assim que possível.
Igor, quanto ao exemplo do pneu, existem pneus de qualidades e preços diferentes, assim como cada peça do veículo. Em software, se suas aplicações são plugáveis, você pode ter determinadas aplicações mais testadas que outras, e é natural fazer isso.
Cara, todo segmento tem suas particularidades, mas o processo de produção do capitalismo é basicamente o mesmo: oferta X demanda. Um tem que justificar o outro.
Sobre custos, depende de qual angulo você vê. Quanto custa o salário de um profissional qualificado pra escrever testes? Sem dúvida é mais alto do que o de um que não é. Todo o processo inicial de adaptação ao processo e nivelamento de equipe também tem custo.
O custo também depende do que você pretende testar. Pegando um exemplo, o Selenium tem uma curva alta pra gerar e manter os testes se você quer ter resultados razoáveis. Então o uso do Selenium tem um custo mais alto do que o de testes unitários. São coisas diferentes, lógico. Mas *o quanto* você vai implementar de cada um depende do resultado que você espera.
Um projeto totalmente sem testes tem um custo alto de manutenção porque tem muito retrabalho.
Um projeto com alta cobertura também tem um custo alto pra manter.
Quer ver como suas aplicações não são bem cobertas de testes?
- Quantas dos seus projetos possuem uma boa Integração Contínua? Rodando em 5 navegadores em 4 sistemas operacionais?
- Você faz controle de Big O?
- Calcula complexidade ciclométrica do seu código?
- Faz métrica da cobertura de testes para coisas como __init__, migrations e imports opcionais?
- Possui vários (uns 5 a 10) bancos de dados de testes com variação de realidades?
- Tem testes automatizados pra desempenho, escalabilidade, stress, situações críticas, corrupção de dados?
- Faz testes de aceitação?
- Testa todas as possíveis histórias do seu software?
- Gera documentação a partir desses testes?
- Testes de segurança em todas as URLs?
- e mais outros testes básicos de modelo, mudanças de estado e processos, que é o mínimo que cada projeto tem que ter...
Cara, se você tem um projeto que tem TUDO isso completo, aí você tem 100% de cobertura.
Aí eu te pergunto: comparando a isso, qual é o percentual de cobertura dos seus projetos? E pergunto: porque você não para tudo agora e faz esses testes em todos os seus projetos? Qual será a resposta? CUSTO/BENEFÍCIO. Tão somente isso.
Vejam que eu estou dizendo isso não é pra desmotivar o uso de testes... pelo contrário, estou tentando dar uma porção de realidade e tentando mostrar que há MUITO o que fazer.
Muito se fala em testes mas pouca gente coloca em prática. Eu defendo e faço TDD o máximo que eu posso, mas não radicalismo :)
O problema de toda boa ideia é que muita gente deixa de questionar o quanto e quando elas são boas.
:)
Marcos Daniel Petry
Acho que vou fugir um pouco do tópico, mas enfim, são algumas dúvidas que temo que são digamos, mais alto nível...
Aqui na UCS trabalhamos com Django a anos, tem muita coisa desenvolvida mas infelizmente, muito pouco do código produzindo é coberto por testes, o que dificulta muito a manutenção, mesmo o Django sendo uma ferramenta fantástica.
Estamos desenvolvendo agora um projeto gigante utilizando Django, e, por motivos obvios (e já citados por muita gente), um dos requisitos é cobrir praticamente todo o sistema por testes. Mesmo estando no início, já sentimos a diferença quanto a produtivodade de desenvolvimento, mesmo assim eu sinto uma certa resistência por parte de alguns programadores do projeto, não sei se é por não enxergarem esse ganho de produtividade, mas é bem complicado fazer com que escrevam os testes da melhor forma possivel.
Outra dificuldade que estou tendo, é na integração de módulos com testes, como disse antes, o projeto é enorme, logo, cada desenvolvedor está encarregado de um módulo, e estes modulos, estão de alguma forma integrados. As vezes, há algumas mudanças no código, como por exemplo um relacionamento que antes era 1:1 e virou 1:N.
Os testes falharão, tanto no módulo que está sob a responsabilidade do desenvolvedor que realizou a alteração, quanto nos outros módulos interligados, cabe ao desenvolvedor realizar o acertos destes testes, mas e os outros módulos? Hoje cada desenvolvedor é responsável por seu módulo, e independente da mudança, é o responsável por realiza-la em seu módulos, e temos alguasm ferramentas para facilitar a comunicação e tal, mas não sei pq não fico contente com esta solução hehe.
http://mdpetry.net
ig...@igorsobreira.com
bom, eu acho que já falei bastante, e não pretendo (nem posso) seguir escrevendo desse tanto... rs... então vou tentar esgotar aqui o que eu tenho a dizer.
Ramiro, não vi o video, mas vou ver assim que possível.
Igor, quanto ao exemplo do pneu, existem pneus de qualidades e preços diferentes, assim como cada peça do veículo. Em software, se suas aplicações são plugáveis, você pode ter determinadas aplicações mais testadas que outras, e é natural fazer isso.
Cara, todo segmento tem suas particularidades, mas o processo de produção do capitalismo é basicamente o mesmo: oferta X demanda. Um tem que justificar o outro.
Sobre custos, depende de qual angulo você vê. Quanto custa o salário de um profissional qualificado pra escrever testes? Sem dúvida é mais alto do que o de um que não é. Todo o processo inicial de adaptação ao processo e nivelamento de equipe também tem custo.
O custo também depende do que você pretende testar. Pegando um exemplo, o Selenium tem uma curva alta pra gerar e manter os testes se você quer ter resultados razoáveis. Então o uso do Selenium tem um custo mais alto do que o de testes unitários. São coisas diferentes, lógico. Mas *o quanto* você vai implementar de cada um depende do resultado que você espera.
Um projeto totalmente sem testes tem um custo alto de manutenção porque tem muito retrabalho.
Um projeto com alta cobertura também tem um custo alto pra manter.
Quer ver como suas aplicações não são bem cobertas de testes?
- Quantas dos seus projetos possuem uma boa Integração Contínua? Rodando em 5 navegadores em 4 sistemas operacionais?
- Você faz controle de Big O?
- Calcula complexidade ciclométrica do seu código?
- Faz métrica da cobertura de testes para coisas como __init__, migrations e imports opcionais?
- Possui vários (uns 5 a 10) bancos de dados de testes com variação de realidades?
- Tem testes automatizados pra desempenho, escalabilidade, stress, situações críticas, corrupção de dados?
- Faz testes de aceitação?
- Testa todas as possíveis histórias do seu software?
- Gera documentação a partir desses testes?
- Testes de segurança em todas as URLs?
- e mais outros testes básicos de modelo, mudanças de estado e processos, que é o mínimo que cada projeto tem que ter...
Cara, se você tem um projeto que tem TUDO isso completo, aí você tem 100% de cobertura.
Aí eu te pergunto: comparando a isso, qual é o percentual de cobertura dos seus projetos? E pergunto: porque você não para tudo agora e faz esses testes em todos os seus projetos? Qual será a resposta? CUSTO/BENEFÍCIO. Tão somente isso.
Vejam que eu estou dizendo isso não é pra desmotivar o uso de testes... pelo contrário, estou tentando dar uma porção de realidade e tentando mostrar que há MUITO o que fazer.
Muito se fala em testes mas pouca gente coloca em prática. Eu defendo e faço TDD o máximo que eu posso, mas não radicalismo :)
O problema de toda boa ideia é que muita gente deixa de questionar o quanto e quando elas são boas.
:)
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
Andrews Medina
2010/8/12 Marinho Brandao <mar...@marinhobrandao.com>:
>
> Quer ver como suas aplicações não são bem cobertas de testes?
>
> - Quantas dos seus projetos possuem uma boa Integração Contínua? Rodando em 5 navegadores em 4 sistemas operacionais?
> - Você faz controle de Big O?
> - Calcula complexidade ciclométrica do seu código?
> - Faz métrica da cobertura de testes para coisas como __init__, migrations e imports opcionais?
> - Possui vários (uns 5 a 10) bancos de dados de testes com variação de realidades?
> - Tem testes automatizados pra desempenho, escalabilidade, stress, situações críticas, corrupção de dados?
> - Faz testes de aceitação?
> - Testa todas as possíveis histórias do seu software?
> - Gera documentação a partir desses testes?
> - Testes de segurança em todas as URLs?
> - e mais outros testes básicos de modelo, mudanças de estado e processos, que é o mínimo que cada projeto tem que ter...
>
Acho que o grande problema dessa thread inicialmente abordado pelo
Ramalho é que estamos falando de testes como 'filosofia' de
desenvolvimento. Como a tecnica usada nos dojos. E que pode facilitar
o desenvolvimento, tornando ele mais ágil.
E não que devemos testar todos os tipos de testes em todos os
projetos. Por exemplo não faz sentido eu fazer teste de seguranca
quando faço um sistema de TODO/Tasks que rodo localmente em minha
máquina, mas desenvolver usando TDD e testes de código podem me fazer
desenvolver o que quero mais rapido, de forma mais coesa e que
qualquer um entenda.
> Cara, se você tem um projeto que tem TUDO isso completo, aí você tem 100% de cobertura.
Na verdade não. Se for ver de forma nao especifica sobre qualidade e
testes, 'há mais formas de testar e mantes a qualidade do supõe nossa
vã Filosofia'. Há testes de usabilidade, acessibilidade, de mercado...
>
> Aí eu te pergunto: comparando a isso, qual é o percentual de cobertura dos seus projetos? E pergunto: porque você não para tudo agora e faz esses testes em todos os seus projetos? Qual será a resposta? CUSTO/BENEFÍCIO. Tão somente isso.
>
Porque fazer testes de código/TDD/BDD que sao focados no objetivo do
codigo é uma coisa. Agora fazer testes que visam outros fins
especificos como performance, segurança, otimização e aprendizado é
outra.
> Vejam que eu estou dizendo isso não é pra desmotivar o uso de testes... pelo contrário, estou tentando dar uma porção de realidade e tentando mostrar que há MUITO o que fazer.
Não é muito bem o que parece.
> Muito se fala em testes mas pouca gente coloca em prática. Eu defendo e faço TDD o máximo que eu posso, mas não radicalismo :)
>
O 'apelo' do Ramalho e a iniciativa dele foi uma forma pratica de
motivar e divulgar que há como testar em Django/Python
> O problema de toda boa ideia é que muita gente deixa de questionar o quanto e quando elas são boas.
Acho que devemos questionar tudo o que fazemos. Todo tempo.
Andrews Medina
2010/8/12 Marcos Daniel Petry <marco...@gmail.com>:
> Poxa, essa thread aqui está boa hein? Só tem ninja por aqui :-)
>
Alias tu é um deles. =)
>
> Estamos desenvolvendo agora um projeto gigante utilizando Django, e, por
> motivos obvios (e já citados por muita gente), um dos requisitos é cobrir
> praticamente todo o sistema por testes.
Parabens a todos da equipe pela iniciativa.
> Mesmo estando no início, já sentimos
> a diferença quanto a produtivodade de desenvolvimento, mesmo assim eu sinto
> uma certa resistência por parte de alguns programadores do projeto, não sei
> se é por não enxergarem esse ganho de produtividade, mas é bem complicado
> fazer com que escrevam os testes da melhor forma possivel.
>
Já passei por isso, e nem todos conseguer ver a importancia dos
testes. Alguns nunca irao ver. =/
Mas uma forma legal é não impor e sim conquistar, mostrando dia a dia
como os testes podem auxiliar, aumentando a velocidade da equipe,
diminuindo tempo com debug e facilidando a evolucao do codigo sem
estragar o que foi feito no passado.
> Outra dificuldade que estou tendo, é na integração de módulos com testes,
> como disse antes, o projeto é enorme, logo, cada desenvolvedor está
> encarregado de um módulo, e estes modulos, estão de alguma forma integrados.
> As vezes, há algumas mudanças no código, como por exemplo um relacionamento
> que antes era 1:1 e virou 1:N.
>
> Os testes falharão, tanto no módulo que está sob a responsabilidade do
> desenvolvedor que realizou a alteração, quanto nos outros módulos
> interligados, cabe ao desenvolvedor realizar o acertos destes testes, mas e
> os outros módulos? Hoje cada desenvolvedor é responsável por seu módulo, e
> independente da mudança, é o responsável por realiza-la em seu módulos, e
> temos alguasm ferramentas para facilitar a comunicação e tal, mas não sei pq
> não fico contente com esta solução hehe.
>
Trabalhei em um caso um pouco parecido. Primeiro voces usam CI
(integração contínua)?
Uma sugestao (nao é escrito em pedra), seria, alem de voces rodarem os
testes na maquinas de voces antes de commitarem algo, deixar o CI
rodando os testes de todos os modulos a cada vez que alguem
commitasse. Assim seria tranquilo ver quando alguem quebra algum
modulo, ou quando um modulo esta com os testes quebrados.
IMHO quando alguem quebra os testes, esse alguem que tem que
consertar. Não importa se ele quebrou testes de modulo dos outros.
Quando eu quebro testes em algo que nao tenho dominio, faço pair
programming com alguem que tenha dominio para corrigirmos junto os
testes.
Por isso acho importante voces sempre rodarem testes dos outros
modulos tambem, durantes o desenvolvimento (antes do commit).
Marinho Brandao
A lista que eu fiz contém só itens que poderiam (e teoricamente deveriam) estar em testes automatizados. Mas isso não quer dizer que sejam viáveis :)
Eu também não sou doido de implementar tudo aquilo nos projetos que eu trabalho, mas o fato é que se levar a coisa pro lado do "escrever testes a qualquer custo" não faz sentido por sí só. Cada caso é uma realidade diferente e exige uma dosagem diferente.
Então, gente, há muito o que fazer, tanto em matéria de melhorar as ferramentas disponíveis quanto em aprofundar mais o conhecimento.
Bernardo Heynemann
Práticas Ágeis de desenvolvimento são assuntos que eu gosto muito de
discutir e acredito ter muito a contribuir.
DISCLAIMER: Este post é longo, mas tentei fazer o mais sucinto
possível. Vamos aos assuntos:
Qualidade
---------
Você afirma que qualidade é uma questão de capitalismo, afinal o prego
da nasa é mais caro que o prego da lojinha do lado da sua casa. Essa é
uma comparação ruim, pois provavelmente o prego da nasa (que prende o
quadro na parede) é mais barato que da lojinha. Por 2 motivos, a) A
Nasa compra milhares de pregos, logo não paga o preço de varejo. b) A
lojinha paga muito mais imposto / aluguel / salarios POR prego do que
a Nasa.
Mas eu gostei mais da comparação da Ferrari vs Gol. A indústria
automobilística é um bom exemplo de qualidade vs produtividade. Henry
Ford foi o primeiro a utilizar a produção em massa que você falou.
A idéia é que se você utilizar 100% de cada uma das suas máquinas e
for produzindo inventório você vai ser produtivo e ganhar mais
dinheiro. Isso se chama sub-otimização. Ao invés de otimizar o todo
você otimiza cada parte.
O grande problema com esse approach é que quando você encontra um
problema com uma das partes e tem que corrigir, você tem centenas
dessa parte em inventório e tem que jogar fora. Pior ainda se essa
modificação afetar outras partes.
Neste ponto surgiram a Toyota e a Honda que pregam o oposto: quanto
maior a qualidade, mais barato é o produto. E para garantir a
qualidade você *PRECISA* poder estar constantemente mudando as partes
dos carros (mesmo durante a concepção do carro e até após o início da
produção do mesmo).
Para que isso seja possível, é imprudente ter inventório. E se você
não vai ter inventório, não faz sentido 100% de utilização das
máquinas. Por isso eles inventaram o Just-In-Time (já ouviu isso né?).
E porque estou falando isso? Porque o processo da Toyota (LEAN) de
produção de carros tem muitos aspectos em comum com o desenvolvimento
de software: os princípios.
Especialmente a mudança! A única coisa de que você tem certeza quando
inicia um projeto é que as coisas vão mudar. E vão mudar de 3 formas
distintas:
a) Antes de você começar a desenvolver, nas conversas com os clientes;
b) Durante o desenvolvimento, quando você descobre mais sobre o
sistema;
c) Após a implantação, quando seus clientes passam a vislumbrar novas
possibilidades;
O que dita o sucesso é quão eficientemente você está apto a reagir a
mudança. Isso me leva ao próximo assunto!
Test Driven Development
-----------------------
O que hoje chamamos de TDD, surpreendentemente é um conceito de 1968
do engenheiro Edsger W. Dijkstra. Chamado Constructive Programming,
Dijkstra afirmava que o jeito de escrever programas corretamente é
criar uma especificação executável que prove que a sua classe de
cálculos faz o que ela deveria fazer e então escrever o código que
torna esta especificação verdadeira.
Entender esta prática de TDD é muito menos importante do que entender
o princípio que ela se baseia. Quando você faz TDD, você escreve o
código após o teste. Isto implica não em mais qualidade (afinal eu
posso escrever os códigos com TDD e eles não fazerem o que o cliente
quer) e sim em código testável. Porque é bom ter código testável?
Código testável é inerentemente código de baixo acoplamento e alta
coesividade. E porque eu quero isso? Porque quando você tem código
coeso, ou seja, todas as operações que dizem respeito ao mesmo assunto
estão juntas, e pouco acoplado, ou seja, você pode alterar código de
uma unidade sem afetar outra, eu me permito reagir RÁPIDO a mudança.
Tá vendo como a prática de TDD não tem como objetivo ter testes que
provam que seu código funciona? Isso é só o processo. O objetivo é ter
capacidade de responder rapidamente (e de forma segura, sem chance de
erros) a mudança.
Além disso a prática de TDD é muito mais voltada ao Design de
aplicações do que à mera função de provar a correção. Por isso que não
acredito muito em métricas de cobertura. Se a cobertura está baixa só
prova que você está escrevendo código sem TDD. Isso em si não é um
problema se você continuar capaz de responder a mudança de forma
eficiente, segura e barata.
Fica claro quando você estuda o processo LEAN que um dos maiores
objetivos para alcançar o sucesso é melhoria contínua. Não basta fazer
bem, quando você pode fazer o excelente. O excelente é sempre mais
barato. E quando você tiver fazendo o excelente, ele vai ser o bom, e
assim sucessivamente.
Python e Ferramentas
--------------------
Como o Andrews bem falou, eu também não aceito o estado atual das
ferramentas de teste ou de tdd ou de qualquer outra coisa.
Aceitar a situação atual, ou a realidade, é aceitar que eu não sou
capaz de melhorar. E esse é um dos princípios LEAN que eu mais
acredito: melhoria contínua.
Se a ferramenta que eu preciso não existe em python, eu escrevo uma e
contribuo com a comunidade. Seria muito bom se todo mundo fizesse
isso. E melhor ainda se essas ferramentas evoluíssem com o tempo
(melhoria contínua?).
Hoje em dia, eu já tenho uma boa parte das ferramentas que preciso pra
desenvolver em python ponta a ponta. Vamos a elas (note que são TODAS
open source):
a) CI - Eu não desenvolvo nenhum projeto profissional sem Continuous
Integration. Ferramenta: Skink
b) Web Framework - O Django me atende muito bem (apesar de eu ter
feito minha própria chamada Ion). Ferramenta: Django
c) Web Server - o Nginx tem sido a melhor opção.
d) Testes Unitários - Nose para rodar e Fudge para mocks.
e) Testes funcionais - Nose para rodar.
f) Testes de aceitação - Pyccuracy para web apps.
g) Migrações de Banco de Dados - Simple Db Migrate ou South.
Ou seja, apesar de ainda não achar as ferramentas perfeitas, o
trabalho que tenho pra montar todo esse ambiente para um novo projeto
é MUITÍSSIMO baixo. Por isso não engulo essa de que para "projetinhos"
baratos, não vale usar TDD ou CI. É muito mais caro fazer assim! Da
mesma forma que a Toyota gasta muito menos por carro (10x menos que a
Ford) para fazer com mais qualidade (média de 4x mais qualidade), eu
gasto muito menos dinheiro dos meus clientes me preocupando com
qualidade.
A percepção de que em Ruby se testa mais se dá pelo fato de que as
pessoas que começaram o ecosistema da linguagem serem MEGA envolvidas
com os princípios LEAN e por isso estimularem esse tipo de pensamento.
Conclusão
---------
Para entender o porquê determinada prática afeta ou não o meu
trabalho, eu SEMPRE tento entender o princípio por trás daquela
prática. TDD e CI tem como princípio abraçar mudança. Se você não
consegue abraçar mudança, está fadado a falha.
Abraços,
Bernardo Heynemann
http://www.pyccuracy.org
On Aug 12, 1:29 am, "i...@igorsobreira.com" <i...@igorsobreira.com>
wrote:
> 2010/8/12 Marinho Brandao <mari...@marinhobrandao.com>
Marinho Brandao
PS: E-MAIL NÃO CORRIGIDO NEM RELIDO, PORQUE MINHA FILHA ESTÁ ME PUXANDO AQUI COM RAZÃO.
bom, primeiramente, seja bem-vindo à lista e à thread. Como eu disse ao Andrews, a Globo.com é uma referência pra nós em matéria de Agile em geral, fico feliz com a sua presença e sua opinião no debate :)
Eu gostaria de ter me esgotado na thread na mensagem anterior. Pessoalmente seria muito mais interessante. Não li todo o seu e-mail, apenas "passei o olho", porque ficou longo e de forma geral, as definições nós conhecemos :)
De uma forma geral, concordamos, então vou comentar apenas o que discordo, ok? Que na verdade é apenas uma coisa.
Caso nº 1:
No exemplo da Nasa, você comete um engano fundamental. A Nasa é uma empresa de tecnologia de ponta, de vanguarda. Ela NÃO compra milhões de parafusos com os que você compra na ferragista. Quem compra milhões de parafusos são empresas da construção civil.
A Nasa cria tecnologias completamente novas e especializadas, de altíssima precisão, que são enviados para a órbita, outros planetas e até para fora do sistema solar. O máximo que um parafuso usado na construção civil se assemelharia a um parafuso de um artefato espacial seria no formato, e olhe lá. Todo material usado ali é produzido com especificações exatas e suas propriedades são calculadas com altíssima precisão. Os fornecedores da Nasa são poucos e altamente especializados, com profissionais muito bem pagos.
Isso de forma alguma pode ser comparado com produtos da construção civil ou da indústria de produção em massa. Por causa de tanta qualidade precisa, o CUSTO de produção da Nasa é alto SIM. Na maioria das vezes nem mesmo dá lucro. Então, podemos ver claramente que há um curva (parabólica), onde num extremo está a indústria sem nenhuma qualificação, que tem custo alto, e na outra ponta está a indústria de ponta, que também tem custo alto, pois seu nível de exigência é muito alto.
Caso nº 2
Quando eu fiz o curso da PMI, há 5 anos atrás, eles também bateram no exemplo da metodologia de Lean da Toyota. Veja bem, estou falando do **PMI**. Também já ví diversos outros cases tomando a Toyota como "exemplo", como de SCRUM, XP, métodos eficazes de gerência (tanto os mais ousados quanto os mais tradicionais) e por aí vai.
Eu pessoalmente **acho** que o maior motivo de todo mundo querer usar a Toyota como exemplo de caso de seu método favorito é porque ela faz sucesso, e todo mundo quer tirar uma casquinha de quem faz sucesso.
Quanto à melhoria contínua, sem dúvidas é um legado importante herdado pelo Agile, mas aqui também está o seu segundo engano.
O ponto que separa a indústria de produtos finais da produção de software é exatamente porque em software (de uma forma geral) não há linha de produção, porque **no aspecto de produção** o software está mais próximo da prestação de serviços do que da manufatura.
O custo do software não tem impacto de matéria prima física, é produto intelectual e pode ser multiplicado a baixíssimo custo. Sua logística também é muito mais dinâmica.
A relação custo x qualidade da indústria automobilística não foge da regra (lembrando a parábola que citei acima). A Toyota fabrica veículos de preço médio. Se você pegar marcas de veículos de ponta, verá que o custo impacta no preço (Ferrari, Bugatti, Lamborghini, etc.). Da mesma forma, se pegar marcas de carros populares, verá que a regra denovo se aplica.
Bom, então pra finalizar (acabei escrevendo muito denovo... rs), eu repito a você a pergunta que fiz ao Igor anteriormente (com outras palavras):
Se você realmente acredita que TODO teste que aumenta a qualidade baixa o CUSTO, então porque não para tudo o que está fazendo e escreve testes em seus projetos para atingir 100% de cobertura? Veja que não estou falando de testes superficiais, e sim de testes aprofundados e complexos (naquele caso dei um exemplo de 5 a 10 bancos (conjuntos de fixtures) de testes e assim por diante).
Eu poderia dizer que a afirmação de que testes *sempre* resultam em aumento da qualidade e redução do custo é uma falácia, porque não se sustenta nem empiricamente, nem em experimentações, mas eu não fiz nenhum desses dois levantamentos, nem sei de cabeça qual tipo de falácia seria o caso (o mais provável que seja um conjunto delas).
Eu sei que o caso da Globo é à parte. Mas o fato é que o nível de testes que vocês implementam lá, uma softwarehouse do interior, com 4 pessoas (em níveis variados) na equipe, não tem condições de implementar. Vocês trabalham em um nível acima da média, compreende?
Quero deixar claro que não estou criticando vocês e nem mais ninguém. É apenas um confrontamento de ideias.
Tranquilo?
Abraço e boa noite
Marinho Brandao
;)
Marinho Brandao
Conclusão: então quer dizer que o Marinho é contra testes, TDD e "a mudança"? (isso surtiu meio apocalíptico)
Resposta: não podia estar mais errado... hehe :) o meu sobrenome é "mudança".
Veja isso: [1]. O Geraldo Reports é um dos meus projetos onde eu mais investi TDD, desde o comecinho, antes de escrever as primeiras linhas. De acordo com o coverage, ele tem 55% de cobertura de código. E é o que menos me dá trabalho pra manter, e talvez o com mais qualidade. Já o pyNFe [2], está parado enquanto espera por justificativa por parte de um cliente, mas foi igualmente preparado com testes. Ambas as bibliotecas precisam de testes, só sobreviveriam com um nível mínimo de testes.
Agora vejam isso [3]. Já o django-plus é porco quanto a testes, mais antigo do que o Geraldo, mas igualmente é estável e funciona bem (e eu uso mais constantemente do que o Geraldo).
Nenhum dos dois tem integração contínua. Eu venho estudando o assunto há mais de ano e assimilando aos poucos pra colocar em prática. O Geraldo vai ter assim que possível, o django-plus, sem chance. O ERP está ganhando um servidor de CI agora por esses dias, mas a maioria das aplicações que eu faço e jogo sob GPL na rede não tem CI e jamais vai ter.
Porque uma CI que se preze precisa ter no mínimo 3 sistemas operacionais * 2 bancos de dados * 5 navegadores, e isso tem um custo que a minha empresa hoje não consegue cobrir para qualquer projeto, tem que ser pensado antes e ser colocado em prática à medida que haja realidade compatível (nenhum defensor fervoroso de CI vai pagar as minhas contas).
Também julgo Big O e complexidade ciclométrica fundamentais, porque são elas que indicam onde pode dar m*rda, e parte delas nem é tão complicado de implementar. Em alguns pontos críticos eu faço o teste, apesar de pecar na notação.
Então veja bem, fora a parte em que eu aplico muito doctests e vocês testes unitários, o ponto de divergência é tão somente a dosagem em relação ao projeto. Simplesmente porque há projetos em que se precisa de mais testes (alguns aliás mais até do que os que o Bernardo listou) e há outros que não justificam, pela forma como o processo ocorreu desde o princípio e como ocorre o procedimento no dia-a-dia (até porque um software depois que vira legado, é muito mais complicado de passar a ser testado).
Ainda vamos ter outras oportunidades de discutir isso, de preferencia pessoalmente, mas por aqui eu acho que já me esgotei :D tem sido um prazer!
PS: Bernardo, depois que o Andrews sugeriu, estou testando o Skink, parece uma boa :) Trombei no MySQL, porque o meu deu pau depois que o MacPorts resolveu pisar na bola comigo esta semana, mas vou coloca-lo numa VM pra testar assim que possível :)
[1] http://github.com/marinho/geraldo/tree/master/geraldo/tests/
[2] http://github.com/marinho/PyNFe/tree/master/tests/
[3] http://github.com/marinho/django-plus/tree/master/djangoplus/tests/
Herberth Amaral
> Pois é... o maldito Selenium... rs... mas enfim, parece que é a única opção, então é nele que eu tenho apostado também.
Serve muito bem para testes funcionais e é em Python. Uma excelente
alternativa ao Selenium.
Marinho Brandao
sim, tentei... mas isso foi há mais de ano, não lembro por qual motivo, mas na época o Selenium me pareceu muito superior.
Também tem o do Zope, que não testei.
Eu realmente preciso investir algo nesse sentido, e também gostei do Qunit (eu não conhecia, foi sugestão do Andrews).
Mas por enquanto eu preciso deixar outras coisas redondas antes de atacar essa parte.
Obrigado :)
> --
> Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
> Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
----
Francisco Souza
2010/8/13 Marinho Brandao <mar...@marinhobrandao.com>
[...]
Se você realmente acredita que TODO teste que aumenta a qualidade baixa o CUSTO, então porque não para tudo o que está fazendo e escreve testes em seus projetos para atingir 100% de cobertura? Veja que não estou falando de testes superficiais, e sim de testes aprofundados e complexos (naquele caso dei um exemplo de 5 a 10 bancos (conjuntos de fixtures) de testes e assim por diante).
Salve Marinho :)
Ter 100% de cobertura apenas para ter 100% ou por que 100% de cobertura agrega valor ao produto? Quanto mais rápido o produto é capaz de reagir a mudanças, maior o valor dele. Como o Heynemann falou, o objetivo do TDD não é provar que seu código funciona, é torná-lo "amigável" às mudanças, é agregar valor ao produto que o código está construindo.
Softwares adaptáveis, capacitados a reagir rápido a mudanças, como o Bernardo citou, são software de qualidade. Escrever testes é só um meio para atingir tal qualidade, mas não é o único meio.
Abraços,
Francisco Souza
Software developer at Giran and also full time
Open source evangelist at full time
English: http://www.franciscosouza.net
Portuguese: http://www.franciscosouza.com.br
Twitter: @franciscosouza
+55 27 3026 0264
Marinho Brandao
Bernardo Heynemann
Essa discussão não podia estar melhor! :)
Primeira coisa: queria me desculpar por ter citado Dijkstra como
engenheiro (correção via @ramgarlic). Ele era matemático e abominava
engenharia de software.
Quanto ao que foi discutido aqui até agora: preciso admitir uma falha
minha. Eu não tinha lido a segunda página (bom pode ser falha do
google groups que eu não entendi que tinha segunda página). Agora eu
li.
De novo queria conversar com vocês sobre qualidade. Eu tenho muita
experiência nessa área. Talvez devesse escrever mais sobre isso (como
curiosidade, meu pai é especialista em qualidade de empresas, sendo um
dos poucos no país apto a certificar indústrias em várias ISO
diferentes - vai ver que tá no sangue, rs rs rs). Eu leio muito sobre
isso também.
Toyota Production System [1]
----------------------------
Também conhecido como Thinking Production System (TPS). O legado da
Toyota não é que ela tem sucesso na manufatura de carros. Isso pouco
me interessa, afinal não estou construindo um carro. Sequer estou
construindo algo físico. No entanto, o TPS não é um conjunto de
práticas. Ele é um conjunto de princípios. São eles:
1) Continuous Improvement (Melhoria Contínua)
2) Respect for People (Respeito pelas pessoas)
3) Long-term philosophy (Filosofia de longo-prazo)
4) The right process will produce the right results (O processo
correto vai produzir os resultados corretos)
5) Add value to the organization by developing your people and
partners (Adicione valor para a organização desenvolvendo suas pessoas
e parceiros)
6) Continuously solving root problems drives organizational learning
(Resolução contínua de problemas raiz leva a aprendizado
organizacional)
Vocês acreditam que algum dos princípios acima se aplica somente a
construção de carros? Existe sequer qualquer menção a carros ou peças?
Não me parece que isso seja a realidade.
Com os princípios acima em mente vou tentar explicar o que o Marinho
perguntou. Espero ter sucesso em ilustrar meu ponto de vista (que de
nenhuma forma considero como verdade absoluta ou critério de aceitação
para se chamar de desenvolvedor ou qualquer outra visão que seja
discriminatória ou negativa).
TDD
---
Como falei no meu outro post, Test-Driven Development (que muitas
vezes eu não faço por preguiça em projetos pessoais, mesmo sabendo que
estou errado) é a prática que me permite reagir rápido a mudanças.
Gostaria de relacionar aos princípios acima, para que vocês possam ver
que a filosofia pregada pelo Lean não é marketing. Muitos usam como
marketing, mas não é assim com tudo? (SOA lembra algo?)
Considerando o primeiro princípio, parece lógico para mim que se eu
quero melhorar meu projeto constantemente e nesse sentido melhorar a
forma que eu trabalho o tempo todo, eu preciso de uma suite de testes
que é minha rede qdo eu salto de um trapézio. Quanta segurança você
precisa varia de caso a caso. Eu diria que se estivesse fazendo o
software que controla um reator nuclear eu iria querer muito mais
segurança do que no software que controla meu blog. No entanto, para
que eu possa realizar os benefícios da melhoria contínua eu preciso
seguir esta prática.
Eu acredito sinceramente que se você trabalha em equipe, você precisa
respeitar seus colegas e ser respeitado de volta. Considero que
escrever o melhor código que você pode é uma atitude de ENORME
respeito pelos seus colegas, visto que eles vão ter que trabalhar no
seu código. Eu fico muito triste e desanimado quando vejo alguém
sofrendo ou ficando desmotivado por trabalhar num código que eu
escrevi (e acontece com mais frequência do que eu gostaria). Sendo
assim, utilizar TDD me faz escrever código mais claro e eficiente.
Considero isso respeito aos meus colegas e a minha empresa.
O terceiro princípio é o de que o objetivo de toda empresa não é o
lucro. É se manter no mercado pra sempre. Esse é o goal das empresas
lean. Prover serviço de qualidade para poder continuar gerando
empregos e garantindo a sobrevivência o melhor possível da empresa. Se
eu pensar em longo prazo, fica muito mais evidente a necessidade de
automatizar o máximo possível de testes, afinal quem quer ficar
testando as mesmas coisas manualmente RELEASE após RELEASE? É um saco!
Agora o ponto que eu mais queria falar!!! **O processo correto é o que
gera resultados corretos**. O corolário[3] disso é que se você está
tendo resultados corretos é porque o seu processo está correto (não
ótimo, pois pode ser melhorado sempre, mas correto).
Você falou de vários tipos de teste aí. Eu posso incluir muitos mais:
carga, stress, stress externo (tem serviços pra isso agora), smoke,
integração, combinatórios, generativos, visuais... A lista é grande!
Eu estudo muito esse assunto e conheço a maioria. No entanto, não uso
nem metade regularmente. "Porquê não?" você pergunta? Afinal todos tem
um propósito justo e aparentemente todos são necessários, certo? Não!
O processo correto é o que gera resultados corretos! Eu uso os tipos
de teste que fazem sentido pra mim no projeto no momento atual. Pode
ser que em um projeto que tem muitos cálculos faça sentido fazer
testes combinatórios, já em um projeto com interface visual rica e
avançada, testes visuais façam mais sentido. O ponto aqui é: NÃO É 8
ou 80! Quaisquer testes que façam sentido automatizar pra você vai ser
a quantidade perfeita se gerar os resultados certos (adaptabilidade a
mudança).
Não existe forma melhor de adicionar valor a um projeto ou organização
do que promovendo aprendizado das pessoas. Por isso que toda vez que
um membro do meu time chega pra mim com uma idéia, eu apóio no ATO!
Sem pensar duas vezes! Existem dois cenários pra mim quando alguém
quer tentar uma idéia:
1) A idéia é fantástica e a equipe e a empresa se beneficiam dela. A
pessoa que teve a idéia e que implementou ela ganha boost de moral e
confiança.
2) A idéia não dá certo e todos os envolvidos aprendem com a falha e
não seguem mais por esse caminho. A pessoa que teve a idéia ganha
confiança pois a equipe acreditou nela.
Qual dos dois cenários é ruim?! Nenhum! Então fazer tipos de teste
diferentes é FANTÁSTICO pois o aprendizado é o caminho pra seguir! É a
melhor forma de motivar profissionais.
E o último princípio é o de que a gente deveria estar resolvendo os
problemas da empresa um atrás do outro, do maior pro menor, de forma a
ter o menor número de problemas possíveis. Para que isso seja verdade
(conforme explicitado inúmeras vezes aqui) é necessário que a gente
esteja apto a reagir o mais rapidamente possível a mudanças.
Ufa, falei pra kct! Prometo que tá acabando!
Continuous Integration
----------------------
Marinho, acho que você não entendeu bem o princípio da integração
contínua de código. O primeiro cara que teve essa idéia não foi o
Martin Fowler[4] como pensamos (eu pensava até um tempo atrás anyway),
foi o Dr. Harlan Mills (também em 1972 como o Dijkstra). Ele falou
sobre Top-Down Design na década de 70!!! E até hoje sofremos para
entender! Eu só vim entender a pouco tempo!
A idéia é que a gente construa as nossas aplicações em pequenos
módulos, um por vez e vá integrando cada módulo com os já existentes
sem quebrar nada (UM POR VEZ). Essa idéia, também conhecida como step-
wise design, foi a precursora da integração contínua. O objetivo da
integração contínua é que os novos códigos (módulos) que você integra
ao seu codebase não quebrem os outros códigos (módulos) que já estavam
lá antes.
Tendo isso em vista, não faz sentido o que você disse sobre os
requisitos para um CI de verdade. Não existe *UM CI*, afinal
integração contínua é a prática de desenvolver de forma modular e
garantir que os módulos novos não quebrem módulos antigos. Os
servidores de integração contínua (como o Skink) só automatizam uma
parte chata desse processo pra gente. A responsabilidade pelo processo
continua sendo nossa.
Conclusão
---------
Lean não é marketing. Eu já pensei assim e até já sacaneei colegas que
vieram falar comigo sobre LEAN! Já me desculpei com todos e hoje em
dia (como falei acima) não descarto NENHUMA idéia de ninguém sem
tentar antes. Por isso não acho que é prudente fazer isso (já fiz como
disse e me dei mal).
As práticas da Toyota não servem pra NADA pra você nem pra mim, pois
não fazemos carros. Mas os princípios servem e SÃO REVOLUCIONÁRIOS. No
entanto, são tão simples que eu sempre penso: "Como nunca pensei
nisso?!!?"
TDD, CI e qualquer outra prática agil só serve pra alguma coisa se for
suportar os valores da sua empresa, do seu projeto e das pessoas
envolvidas. Isso é uma coisa que tenho conversado muito na globo.com
com várias pessoas. Vocês sabe os seus valores? E os da sua equipe? E
os do seu projeto? E os da sua organização? Se as pessoas não sabem os
valores que deveriam guiar as decisões, as decisões são tomadas
baseado em wishful thinking[2] (não vou falar aqui sobre wishful
thinking pois já está grande d+!). E isso não é nada bom!!!
Se você leu até aqui muito obrigado por achar que eu tenho algo
relevante a dizer!!!
[1] http://en.wikipedia.org/wiki/Toyota_Production_System
[2] http://pt.wikipedia.org/wiki/Wishful_thinking
[3] http://pt.wikipedia.org/wiki/Corol%C3%A1rio
[4] http://martinfowler.com/articles/continuousIntegration.html
Abraços,
Bernardo Heynemann
On Aug 14, 10:30 am, Marinho Brandao <mari...@marinhobrandao.com>
wrote:
>
> O caminho é exatamente esse :D
>
> Em 14/08/2010, às 08:51, Francisco Souza escreveu:
>
> > [...]
>
> > Se você realmente acredita que TODO teste que aumenta a qualidade baixa o CUSTO, então porque não para tudo o que está fazendo e escreve testes em seus projetos para atingir 100% de cobertura? Veja que não estou falando de testes superficiais, e sim de testes aprofundados e complexos (naquele caso dei um exemplo de 5 a 10 bancos (conjuntos de fixtures) de testes e assim por diante).
>
> > Salve Marinho :)
>
> > Ter 100% de cobertura apenas para ter 100% ou por que 100% de cobertura agrega valor ao produto? Quanto mais rápido o produto é capaz de reagir a mudanças, maior o valor dele. Como o Heynemann falou, o objetivo do TDD não é provar que seu código funciona, é torná-lo "amigável" às mudanças, é agregar valor ao produto que o código está construindo.
>
> > Softwares adaptáveis, capacitados a reagir rápido a mudanças, como o Bernardo citou, são software de qualidade. Escrever testes é só um meio para atingir tal qualidade, mas não é o único meio.
>
> > Abraços,
> > Francisco Souza
> > Software developer at Giran and also full time
> > Open source evangelist at full time
>
> > English:http://www.franciscosouza.net
> > Portuguese:http://www.franciscosouza.com.br
> > Twitter: @franciscosouza
>
> > 2010/8/13 Marinho Brandao <mari...@marinhobrandao.com>
Marinho Brandao
> Essa discussão não podia estar melhor! :)
Fora a parte que a gente se empolga e escreve pra caramba, tudo bem... kkkk :P
> Quanto ao que foi discutido aqui até agora: preciso admitir uma falha
> minha.
Sem problemas, eu cometo falhas de digitação e releitura o tempo todo, você tem muito saldo pra gastar :)
> De novo queria conversar com vocês sobre qualidade. Eu tenho muita
> experiência nessa área. Talvez devesse escrever mais sobre isso (como
> curiosidade, meu pai é especialista em qualidade de empresas, sendo um
> dos poucos no país apto a certificar indústrias em várias ISO
> diferentes - vai ver que tá no sangue, rs rs rs). Eu leio muito sobre
> isso também.
Por isso é uma referência!
> práticas. Ele é um conjunto de princípios. São eles:
Eu havia me esquecido dos princípios da Toyota. Concordo TOTALMENTE.
> Como falei no meu outro post, Test-Driven Development (que muitas
> vezes eu não faço por preguiça em projetos pessoais, mesmo sabendo que
> estou errado) é a prática que me permite reagir rápido a mudanças.
Agora estamos falando a mesma língua :P
Isso se chama "realidade". Na tal realidade existem casos e casos. Ontem por exemplo eu fiz um radarzinho brincando e publiquei na web (sem nenhuma pretensão), já pensou se eu fosse escrever testes e criar simulações pra isso? Deixaria de ser divertido (é só um hobby), mas pode ser que um dia isso se transforme num projeto maior, livre e aberto na web, e sem testes, por conta de ter virado legado. É aí que entra o "depende" da coisa :)
> O terceiro princípio é o de que o objetivo de toda empresa não é o
> lucro. É se manter no mercado pra sempre. Esse é o goal das empresas
Ponto pra você, faz sentido.
> Agora o ponto que eu mais queria falar!!! **O processo correto é o que
> gera resultados corretos**. O corolário[3] disso é que se você está
(trollando) a teoria do caos às vezes fala mais alto, mas aí é outra coisa.
> Você falou de vários tipos de teste aí. Eu posso incluir muitos mais:
> carga, stress, stress externo (tem serviços pra isso agora), smoke,
> integração, combinatórios, generativos, visuais... A lista é grande!
Sim, eu esqueci de colocar um "etc." no final. Na verdade isso é exatamente isso que derruba o argumento de "tudo ou nada" empiricamente. Se "testar tudo" fosse sempre "menos custo", então ficaríamos eternamente criando mais e mais testes e nunca implementando. Fail :)
> avançada, testes visuais façam mais sentido. O ponto aqui é: NÃO É 8
> ou 80! Quaisquer testes que façam sentido automatizar pra você vai ser
> a quantidade perfeita se gerar os resultados certos (adaptabilidade a
> mudança).
Sim, e este "faça sentido" vai depender do quanto de qualidade se espera, porque a qualidade tem que ser paga por alguém. Se uma prática reduz os custos (caso dos testes mais comuns), então ótimo. A partir do momento que essa prática passa a aumentar os custos, alguém tem que pagar a conta. Dependendo do projeto, o sponsor vai pagar... dependendo, ele não vai pagar, porque não pode ou porque não quer.
> Marinho, acho que você não entendeu bem o princípio da integração
> contínua de código. O primeiro cara que teve essa idéia não foi o
> Martin Fowler[4] como pensamos (eu pensava até um tempo atrás anyway),
Se não me engano o próprio Martin Fowler fala isso naquele texto inicial dele sobre CI, não? Tem aquela história que ele conta como observou outras empresas trabalharem e tal. Enfim, já faz um tempo que eu li isso, mas tenho quase certeza de que ele deixa claro que a autoria não é dele.
> wise design, foi a precursora da integração contínua. O objetivo da
> integração contínua é que os novos códigos (módulos) que você integra
> ao seu codebase não quebrem os outros códigos (módulos) que já estavam
> lá antes.
A forma como eu sei **testar** isso de forma prática é abrindo várias instâncias em realidades diferentes (as que o projeto exige) e rodando sempre que soltar uma nova release (ou a cada commit, dependendo do caso). Ademais, são testes como parte do TDD convencional.
Digo isso porque a prática em sí, é uma questão humana.
> Tendo isso em vista, não faz sentido o que você disse sobre os
> requisitos para um CI de verdade. Não existe *UM CI*, afinal
Sim, sim... na verdade eu "forcei a barra" pra você entender que o raciocínio de 100% de cobertura não faria sentido neste caso, já que um teste "completo" de CI exigiria muito mais do que cada projeto em seu próprio caso exigiria.
Observe que na minha pergunta (daquela parte do texto em diante) eu tento te mostrar que cada caso é um caso e que apenas dizer que há uma solução ótima para todos os casos é falácia.
> Lean não é marketing. Eu já pensei assim e até já sacaneei colegas que
> vieram falar comigo sobre LEAN! Já me desculpei com todos e hoje em
> dia (como falei acima) não descarto NENHUMA idéia de ninguém sem
> tentar antes. Por isso não acho que é prudente fazer isso (já fiz como
> disse e me dei mal).
Não é, mas concorda que virou chavão citar o Lean e Toyota como exemplos de sucesso pra qualquer coisa? Assim como virou chavão citar o Hitler e o nazismo como paralelo pra qualquer coisa ruim.
Já vi gente dizer: "tem que aplicar o modelo de gestão da Toyota na política". É mais ou menos como dizer: "nossos políticos tem que ser honestos".
Quero dizer: é óbvio, mas isso não diz nada no aspecto de como ser colocado em prática. Soa como conversa de barbeiro de como resolver os problemas do mundo.
> com várias pessoas. Vocês sabe os seus valores? E os da sua equipe? E
> os do seu projeto? E os da sua organização? Se as pessoas não sabem os
> valores que deveriam guiar as decisões, as decisões são tomadas
> baseado em wishful thinking[2] (não vou falar aqui sobre wishful
> thinking pois já está grande d+!). E isso não é nada bom!!!
É verdade. Já me chamaram de cafona por ter uma Missão Pessoal (dica do Stephen Covey), mas eu acho fundamental. Pelo menos pra mim é fundamental.
> Se você leu até aqui muito obrigado por achar que eu tenho algo
> relevante a dizer!!!
Sem dúvida. Quando eu cito vocês como exemplo, não é demagogia não. É de verdade (acho que todo mundo já sabe que eu sou bocudo né? rs). Então não tenha dúvidas. É exatamente por achar isso que eu insisto no debate.
Fazendo uma observação (construtiva) sobre as suas duas mensagens: a primeira me decepcionou, soôu como se eu tivesse uma tatuagem "burro" na testa. Nesta você esteve à altura que eu esperava. Obrigado por ter percebido isso e mudado o discurso :)
Bom dia e boa semana pra todos!
Bernardo Heynemann
Então, off-topic agora!
Acho muito ruim o formato escrito de listas para discussão, pois fica
muito impessoal e muitas vezes a galera confunde argumentos com
arrogancia. Me desculpe se foi essa a imagem que passei no primeiro
post. Não era meu objetivo e não acho que ninguém aqui tem "tatuagem
de burro na testa". Acho sim, que nossa profissão é jovem e que na
prática estamos inventando tudo isso agora conforme vamos aprendendo.
No entanto, existem maneiras comprovadas de aprendizado de novas
teorias em outras áreas mais antigas (Filosofia vem a cabeça). Esse é
um dos meus maiores interesses hoje! Como fomentar aprendizado entre
eu e meus colegas. Como fomentar que minha empresa se transforme em
uma organização de aprendizado.
Novamente, mil desculpas se meu post fez você se sentir mal. Nunca foi
minha intenção.
Abraços,
Bernardo Heynemann
On Aug 16, 8:52 am, Marinho Brandao <mari...@marinhobrandao.com>
wrote:
Tiago Brandes
Bom dia galera,
Concordo com o Igor e o Andrews quando dizem que TDD é uma forma de
desenvolver. É uma metodologia que pode ser empregada
independentemente dos requisitos do sistema que vc está desenvolvendo
(lembrando que TDD não tem tanto a ver com testes em si, e sim com a
prática de criar os testes antes do código. Testes de código já
existiam muito antes de TDD surgir). Mas não acredito que seja a
metodologia certa para todos os tipos de projetos.
Apesar do que os "evangelistas" insistem em dizer, TDD é sim mais
caro, no sentido de que leva mais tempo para desenvolver o código.
Claro que, para projetos complexos de longo prazo, o tempo que vc leva
pra desenvolver os testes é compensado pelo modularidade do código e a
confiança que vc tem nele. Mas para projetos rápidos, aquele CRUD
básico para ser usado pelo pessoal do RH da empresa que vc trabalha,
acho que TDD é um exagero e não é necessário.
Outro comentário que quero deixar é sobre testes de interface, ou,
pior ainda, de navegador.. Implementei uma certa dose de testes de
interface no sistema que estou desenvolvendo no meu trabalho em tempo
integral, e foi o suficiente pra me convencer de que não valem a pena.
Nesse momento alguns devem imaginar "ah, ele não soube fazer certo,
não usou a ferramenta certa". Pelo contrário, inclusive usei um
pattern MVP que alguns devem conhecer, e criei o Presenter desde o
início com TDD. Resultado: funcionou, mas os testes "amarraram" a
interface de um jeito que acabei precisando me livrar deles quando
tive que fazer uma alteração grande. Trata-se de uma aplicação desktop
feita em .NET, e as classes de domínio estão perto dos 700 testes e só
me dão alegria :)
O que aprendi foi que interfaces são muito "voláteis" e o benefício
dos testes não justifica o alto custo de modificação do código.
Interfaces mudam o tempo todo de acordo com os requisitos dos
clientes, e também a medida em que melhoramos o seu design. Imagino
que testar no navegador deve ser ainda mais complicado, por isso fico
meio receoso quando vcs comentam sobre Selenium e ferramentas do tipo.
"Brittle" é a palavra que estou pensando, mas não sei traduzir pra
portguues!
Então meu recado é o seguinte: não se preocupem tanto com cobertura do
código na interface. No fundo o que importa é deixar seus clientes
satisfeitos, e não se esqueçam que a interface é, pra eles, o
"sistema". Quero dizer, eu prefiro não usar testes de interface para
ter uma liberdade maior de redesign, e nunca deixei de fazer uma
melhoria na interface por pensar "caramba, vou ter que mudar X testes,
vai levar horas".
-
Tiago Brandes
Bernardo Heynemann
Então... Eu já senti a mesma dor que você muitas vezes. No projeto que
eu estou, temos testes de aceitação web, pois não é aceitável pra
globo.com falhas na interface (e nossas interfaces são bem user-
experience intensive). Como é importante pra gente esse tipo de
confiança ter testes de aceitação é essencial.
Antigamente, a galera disse a mesma coisa que você acabou de falar:
"Deixa pra lá testes de interface. Se a gente tiver cobertura
suficiente da parte server tá bom pra kct."
O que aconteceu? Temos um legado GIGANTE de Javascript, CSS e HTML sem
testes e mal escrito (pois a prática de TDD ajuda a escrever melhor o
código).
Eu mantenho minha opinião de melhoria contínua. Se meus testes estão
ruins vou pensar uma forma melhor de fazê-los. O pyccuracy é uma
tentativa de fazer isso. É melhor que os testes selenium puros? Pra
mim é... É perfeito? Não! Tem que melhorar muito ainda. Testes visuais
ainda são muito difíceis de automatizar, mas eu tenho esperança de
melhorar isso.
Eu trabalhava com .net 2 anos atrás e sempre tentei automatizar testes
de interface web. Era muito difícil no início e eles não cumpriam o
propósito de apoiar a minha capacidade de mudança (o que vc reclamou).
Daí melhorei eles e começou a ser razoavelmente fácil mudá-los. Mas
não fiquei satisfeito, porque o meu objetivo com testes é que eles me
ESTIMULEM a mudar. Melhorei mais com minha equipe os testes de
aceitação: O Accuracy nasceu! :)
A minha mensagem é: não desista de cara porque seus testes de
interface são brittle. Se a interface é uma parte importante da sua
aplicação, você vai ter que testar manualmente cada modificação, não
vai? Se você vai testar manualmente, porque não automatizar? A
primeira automatização vai ser brittle. Não desista, continua
evoluindo os testes. Em algum momento eles vão apoiar você à mudança e
não atrapalha a mudança.
Abraços,
Bernardo Heynemann
Abraços,
Bernardo Heynemann
Marinho Brandao
Tranquilo, Bernardo, sem stress :) eu gosto de encarar a tudo com humildade de quem tem mais a aprender do que a ensinar, então pra mim essa conversa foi um aprendizado constante.
Sobre Pyccuracy, como está o comportamento dele em relação a funcionalidades com JavaScript e Ajax? algum suporte?
Hoje o meu calcanhar de aquiles tem sido interface, o que mais aproximou foi o Seleniun, mas pelo que levantei à época (acho que uns 2 anos atrás ou mais, não estou certo) ele é desajeitado e complicado de manter - inviável pra nossa realidade.
Gostei muito do QUnit, mas ele parece que ele só atende uma parte dos testes (só os unitários mesmo, sem cenário nem história). Então se o Pyccuracy atendesse isso (ou se alguém me mostrasse que o Seleniun não é o bicho de 7 cabeças que parece) eu ficaria MUITO feliz :)
Abraço!
> --
> Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
> Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
----
Andrews Medina
2010/8/17 Marinho Brandao <mar...@marinhobrandao.com>:
>
> Sobre Pyccuracy, como está o comportamento dele em relação a funcionalidades com JavaScript e Ajax? algum suporte?
>
o pyccuracy definindo em um termo mal polido: 'é uma abstração para o
selenium', ou seja, tudo que o selenium faz, ele faz.
> Gostei muito do QUnit, mas ele parece que ele só atende uma parte dos testes (só os unitários mesmo, sem cenário nem história). Então se o Pyccuracy atendesse isso (ou se alguém me mostrasse que o Seleniun não é o bicho de 7 cabeças que parece) eu ficaria MUITO feliz :)
>
O Selenium 2 ta vindo bem mais facil de usar e bem mais rapido, ele é
a fusao do selenium (1) e o webdriver. Usando tecnicas que o jssh,
usando plugins adicionados aos proprios navegadores como drivers.
Eu tambem gosto muito do qunit, mas ele é mais focado no JS em si e
não no contexto todo (como voce falou, unitarios).
Há outras ferramentas para testar javascript bem legais tambem:
jasmine (bdd) - http://github.com/pivotal/jasmine
hanoi, que é um runner multi browser para qunit -
http://github.com/jodosha/hanoi
jspec, que é estilo o rspec - http://github.com/visionmedia/jspec
jscoverage, para medir a cobertura - http://siliconforks.com/jscoverage/
jsunit, unittest para javascript - http://www.jsunit.net/
[]'s
Andrews Medina
www.andrewsmedina.com
Marinho Brandao
> o pyccuracy definindo em um termo mal polido: 'é uma abstração para o
> selenium', ou seja, tudo que o selenium faz, ele faz.
Então deve nos atender :D
> O Selenium 2 ta vindo bem mais facil de usar e bem mais rapido, ele é
> a fusao do selenium (1) e o webdriver. Usando tecnicas que o jssh,
> usando plugins adicionados aos proprios navegadores como drivers.
Bom, se o Pyccuracy atender, não preciso mexer com Selenium, mas bom saber que o novo Selenium vai facilitar as coisas. Vou procurar saber mais.
> Há outras ferramentas para testar javascript bem legais tambem:
>
> jasmine (bdd) - http://github.com/pivotal/jasmine
> hanoi, que é um runner multi browser para qunit -
> http://github.com/jodosha/hanoi
> jspec, que é estilo o rspec - http://github.com/visionmedia/jspec
> jscoverage, para medir a cobertura - http://siliconforks.com/jscoverage/
> jsunit, unittest para javascript - http://www.jsunit.net/
Exceto o jsunit, todos são novidade pra mim.
Obrigado :)
Tarsis Azevedo
Tarsis Figueredo Azevedo.
-------------------
Linux User: #496982
-------------------
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-Martin Fowler, Refactoring: Improving the Design of Existing Code"
Renne Rocha
2010/8/17 Tarsis Azevedo <tarsis....@gmail.com>:
Bernardo Heynemann
passam. :)
Marinho, o Pyccuracy é exatamente para tornar o uso do Selenium mais
tolerável e para tornar seus testes mais legíveis. Dá uma olhada na
documentação em http://www.pyccuracy.org. Lá você vai ter uma idéia
melhor sobre o que a ferramenta faz ou não faz.
Abraços,
Bernardo Heynemann
On Aug 17, 1:10 pm, Andrews Medina <andrewsmed...@gmail.com> wrote:
> Ola,
>
> 2010/8/17 Marinho Brandao <mari...@marinhobrandao.com>:
>
>
> > Sobre Pyccuracy, como está o comportamento dele em relação a funcionalidades com JavaScript e Ajax? algum suporte?
>
> o pyccuracy definindo em um termo mal polido: 'é uma abstração para o
> selenium', ou seja, tudo que o selenium faz, ele faz.
>
> > Gostei muito do QUnit, mas ele parece que ele só atende uma parte dos testes (só os unitários mesmo, sem cenário nem história). Então se o Pyccuracy atendesse isso (ou se alguém me mostrasse que o Seleniun não é o bicho de 7 cabeças que parece) eu ficaria MUITO feliz :)
>
> O Selenium 2 ta vindo bem mais facil de usar e bem mais rapido, ele é
> a fusao do selenium (1) e o webdriver. Usando tecnicas que o jssh,
> usando plugins adicionados aos proprios navegadores como drivers.
>
> Eu tambem gosto muito do qunit, mas ele é mais focado no JS em si e
> não no contexto todo (como voce falou, unitarios).
>
> Há outras ferramentas para testar javascript bem legais tambem:
>
> hanoi, que é um runner multi browser para qunit -http://github.com/jodosha/hanoi
> jspec, que é estilo o rspec -http://github.com/visionmedia/jspec
> jscoverage, para medir a cobertura -http://siliconforks.com/jscoverage/
Osvaldo Santana
--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>
--
Osvaldo Santana Neto — Triveos Tecnologia
Phone: +55 41 9244-1646
Francisco Souza
2010/8/17 Osvaldo Santana <osan...@triveos.com>
Oi Bernardo,Conhece alguma ferramenta que permita fazer os mesmos tipos de testes possíveiscom o Pyccuracy usando a linguagem de programação Python no lugar de en-us/pt-br?Ou ainda: é possível fazer isso com o Pyccuracy?Ou isso é exatamente o que a API programável do Selenium já faz e eu estou fazendo uma pergunta "mané"? :D
É o que a API programável do Selenium já faz :D
Abraços,
Francisco Souza
Software developer at Giran and also full time
Open source evangelist at full time
English: http://www.franciscosouza.net
Portuguese: http://www.franciscosouza.com.br
Twitter: @franciscosouza
+55 27 3026 0264
Marinho Brandao
Quando saiu o site e a primeira versão do Pyccuracy eu o testei, nem lembrava mais que era sobre o Selenium :)
Luciano Ramalho
> "Brittle" é a palavra que estou pensando, mas não sei traduzir pra
> portguues!
brittle = quebradiço
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
ig...@igorsobreira.com
Oi Bernardo,Conhece alguma ferramenta que permita fazer os mesmos tipos de testes possíveiscom o Pyccuracy usando a linguagem de programação Python no lugar de en-us/pt-br?Ou ainda: é possível fazer isso com o Pyccuracy?Ou isso é exatamente o que a API programável do Selenium já faz e eu estou fazendouma pergunta "mané"? :D
Pergunto isso porque *pessoalmente* não gosto muito de ferramentas que criamDSLs (mas isso é preferência pessoal/questão de gosto).
--
Igor Sobreira
www.igorsobreira.com
Bernardo Heynemann
pra reforçar a comunicação com os clientes em uma linguagem que eles
entendem. Código pode parecer mais natural pra gente, mas não pro seu
cliente (na maioria dos casos).
Se não existe comunicação com os clientes, de nada adianta seus testes
serem uma ferramenta nesse sentido. É o caso da maioria. A comunicação
com o cliente é muito fraca. Assim nem faz muita diferença como você
faz seus testes de aceitação.
Abraços,
Bernardo Heynemann
On Aug 17, 9:35 pm, "i...@igorsobreira.com" <i...@igorsobreira.com>
wrote:
> 2010/8/17 Osvaldo Santana <osant...@triveos.com>
ig...@igorsobreira.com
O objetivo de escrever os testes de aceitação em linguagem natural é
pra reforçar a comunicação com os clientes em uma linguagem que eles
entendem. Código pode parecer mais natural pra gente, mas não pro seu
cliente (na maioria dos casos).
Se não existe comunicação com os clientes, de nada adianta seus testes
serem uma ferramenta nesse sentido. É o caso da maioria. A comunicação
com o cliente é muito fraca. Assim nem faz muita diferença como você
faz seus testes de aceitação.
--
Igor Sobreira
www.igorsobreira.com