Produtividade e a cultura do test-first
É comum as pessoas assistirem palestras/workshops/evangelizações/s.a. sobre test-driven development (TDD) e ficarem empolgadas para começar a escrever testes automatizados nos softwares que desenvolvem, mas quando começam a desenvolver, sentem-se perdidas e improdutivas, daí desistem. Testar primeiro é uma cultura, e ninguém muda de cultura só por que ficou empolgado com uma apresentação sobre uma cultura diferente. Passada a empolgação, entendendo os benefícios do TDD, acreditando no TDD e desejando realmente praticar TDD, um desenvolvedor ainda vai ser “pouco produtivo” com TDD.
Digamos que um desenvolvedor precise de um tempo x para implementar entregar uma funcionalidade de um sistema, é óbvio que ele vai gastar um tempo maior que x para entregar esta funcionalidade com TDD, por que ele não escreve só a funcionalidade, escreve também os testes que garantem o funcionamento da mesma. Pensando dessa forma, é óbvio que qualquer desenvolvedor, ainda que seja um TDD Jedi Certified Developer, será menos produtivo fazendo TDD. Assumindo que produtividade é a relação entre codificação e tempo, fazer TDD significa perder produtividade, e aqui começam os problemas culturais…
Um desenvolvedor rápido, com a incrível capacidade de produzir 5 linhas de código por segundo, realmente é um desenvolvedor mais produtivo? Programar é só digitar? Quanto mais código você cospe em um programa, mais produtivo você é? Se eu escrever muito código em pouco tempo serei produtivo ainda que o código escrito não funcione ou seja lixo? Quando você entrega a funcionalidade para o cliente, qual garantia ele tem que tal funcionalidade realmente funciona?
Mensurar produtividade fazendo TDD significa levar em consideração que produtividade é a relação entre a quantidade de funcionalidades implementadas e o tempo que elas levam para serem implementadas, entendendo que a definição de “implementar a funcionalidade x” é construir um software capaz de atender a uma necessidade ou a um desejo do seu cliente, e certamente é um desejo/necessidade do seu cliente que todas as funcionalidades implementadas funcionem. Não estou defendendo que softwares escritos com TDD não possuem bugs, mas que os bugs em softwares escritos com TDD aparecem com menor frequência e, quando aparecem, são detectados com maior facilidade.
Entregar uma funcionalidade testada e funcionando significa que caso ela não seja aprovada pelo cliente, o motivo provavelmente não será por que o seu cliente viu uma exception na tela quando ele clicou naquele botão que você estava torcendo para ele não clicar ou um erro maluco da sua aplicação. Sua funcionalidade não ficará imune à desaprovação do seu cliente: seu cliente poderá dizer “não era isso que eu queria”, problemas de comunicação estão fora do escopo do TDD, mas certamente seu cliente não vai ficar decepcionado por investir tempo em uma apresentação de um software ou uma funcionalidade que simplesmente não funciona.
Portanto, não pense ser estranho o fato de você se considerar menos produtivo fazendo TDD. Na cultura tradicional de desenvolvimento de software, todas as pessoas são pouco produtivas quando fazem TDD. O conceito de produtividade em TDD é outro, e neste contexto, quando você não faz TDD, é impossível sequer ser produtivo, pois se você não pode garantir o funcionamento correto de uma funcionalidade, não existe nenhuma garantia que você não está gastando seu tempo produzindo código morto.
Otimo post cara! Parabens!
Porem….
Acho q tem uma “meia verdade” ai.
Vamo la: Se voce demora 10 minutos escrevendo um teste, que vai testar seu programa “pra sempre” em alguns segundos, vc investiu 10 min, pra ganhar na frente.
Se voce pensar que sem o teste automatizado vc levaria 5 min pra testar a mesma coisa “na mao”, e que vc teria que testa-la varias vezes no dia, logo esses 5 min se transformam em 1hr por dia.
Sendo assim, tirar um certo tempo pra escrever o teste é um investimento a longo prazo. ;D
Nao sei se vc pensa assim, mas essa é minha visao! ;D
Abraços cara!!
Salve Tarsis, valeu o feedback :)
Concordo com sua visão, mas mantive a abordagem do post no benefício do TDD também a curto prazo, pois as pessoas tendem a usar o argumento da produtividade desta forma para mostrar que TDD não vale a pena.
Existem diversos outros pontos quando não se faz TDD (ou BDD, ou algo do tipo), como o fato de comumente escrever-se mais código do que o necessário (enchendo o software de código morto).
Edit: Adicionando apenas uma consideração, geralmente as pessoas mensuram produtividade considerando o tempo em que a funcionalidade é digitada (a.k.a. implementada). Se você gasta 5 minutos digitando o código de uma funcionalidade, significa que você implementou ela em cinco minutos e se você passar 40 minutos testando essa funcionalidade, você ainda vai ser considerado produtivo, porque a implementação é totalmente separada do teste, apesar de ser feita pela mesma pessoa. É apenas mais um furo nesse método de medir a produtividade de um digitador de código.
[...] This post was mentioned on Twitter by Francisco Souza, Tarsis Azevedo. Tarsis Azevedo said: RT @franciscosouza: Produtividade e a cultura do test-first: http://bit.ly/bLnhK6 #tdd #blog #post [...]
O problema é sempre nas “Falsas verdades absolutas” que carregamos! Varias pessoas nao conseguem abrir a mente pra enxergar isso! Ai é osso!
E junte isso ao “otimo” ensino nas faculdades de TI, que mais parece uma escola medieval ensinando novas tecnologias de 10 anos atras, e mais professores que nao se atualizam, e alunos que só copiam e nao questionam.
O resultado da soma acima é um “analista/arquiteto/eng” de sistema! #Tenso
Mandou bem nas palavras meu amigo do quarto ao lado. (:
Apesar de eu não ser PPL em testes e também me considerar menos produtivo com TDD, ainda sim creio ser a melhor forma para uma código seguro, evitando retrabalho.
Espero na medida do possível aprender e escrever mais testes.
Ótimo post, parabéns!
O paradoxo é que TDD tem pouco a ver com testes :)
Na verdade, TDD ainda é um nome não muito certo a meu ver por causa disso: TDD não tem muito a ver com testes. Por isso que o Dan North criou o BDD: o nome “Teste” atrapalhava a compreensão dos alunos que ele ensinava a técnica (também tem o lance do BDD ser mais ubíquo, human friendly – principalmente se vc usa linguagens fáceis de ler como Python e Ruby).
TDD é uma especificação executável que você escreve antes de escrever uma unidade do seu software (geralmente um método). Depois que você escreveu e a unidade passou no teste, o teste que você escreveu fica como teste de verdade mesmo. Aí você pode usa-lo para refatorar seu código, testar seu código em outro ambiente, utilizar como base de testes de regressão, etc.
Quer ter uma boa inspiração para usar testes sem desculpas? Dá uma olhada nesse post: http://herberthamaral.com/2010/06/parabens/
Acho que cada profissional precisa vencer duas grandes barreiras para só então dizer que desenvolve utilizando TDD:
1. A idéia de que se perde tempo com TDD. É aquela velha história: “Não temos tempo pra isso”
2. Mudança no design. TDD não é apenas falar “vou escrever testes”, é necessario que o design do código permita isso (e aí o conceito de test-first ajuda bastante), e isso para algumas pessoas significa uma mudança muito grande na forma de pensar.
[...] Read the original: Produtividade e a cultura do test-firstFrancisco Souza | Francisco … [...]
Para dizer que uma técnica leva mais tempo é necessário experimentos. E nem sempre aquilo que parece intuitivo realmente é verdade. No caso do TDD, a nossa intuição pode levar a crer que levamos mais tempo porque escrevemos mais código(codigo de testes e de produção).
Contudo existem alguns fatores no TDD que podem fazer com que o tempo seja diminuído. Para indicar só um deles, o tempo que perdermos debugando. Praticantes do TDD acreditam (inclusive eu) que o tempo debugando cai drasticamente quando o TDD é realmente bem aplicado.
O meu tcc foi justamente sobre o TDD e fiz um levantamento na época dos papers onde haviam estudos do impacto do TDD no desenvolvimento. Em alguns o tempo dispendido com TDD foi maior e em outros foi menor. Exemplo onde o TDD foi bem melhor no quesito produtividade:
A Influência do Desenvolvimento Orientado a Testes no Projeto do Software [39]:
* Três grupos: Iterativo com TDD, iterativo com TLD(testes construídos no final da iteração), Linear com Testes no Final
* Todos deveriam criar os testes automáticos
A última equipe não o fez (cronograma). Virou Sem Testes
TDD:
* Dobro de características implementadas
* Esforço: -88% (comparado ao Sem Testes) -57% (compardo ao TLD)
* + linhas de código
* 86% mais caminhos que TLD
*Inspeção manual: melhor distribuição de classes e responsabilidades
* Visão positiva dos programadores depois de utilizaçao
E um exemplo onde o TDD foi pior na produtividade, mas bem melhor na qualidade externa:
Avaliando a Eficácia do Desenvolvimento Orientado a Testes [99]
*Dois ambientes Microsoft (Windows e MSN)
*Aumento significante na qualidade do código, do ponto de vista de defeitos/KLOC, (pelo menos duas vezes maior)
* Pelo menos 15% mais tempo
*Adicionalmente:
autodocumentação bibliotecas/APIs tanto para utilização, como para manutenção.
No conjunto de estudo que tive acesso (acho que 14) fiz a seguinte contabilidade: 1 ponto se na característica o TDD fosse melhor, 0 se fosse neutro ou não tivesse sido estudado, -1 se fosse pior. O resultado foi o seguinte:
Produtividade = 1
Qualidade Externa = 11
Qualidade Interna = 2
Observe que nem todos os estudos levaram todos os parâmetros em consideração. Por exemplo, vários não verificaram a qualidade interna.
Não sei como vai ficar a formatação, mas segue a tabela:
P QE QI
-1 2 0 [9]
0 1 0 [44]
0 1 0 [7]
1 1 1 [39]
-2 2 0 [99]
1 1 [88]
0 1 [40]
1 1 [101]
1 [102]
1 0 [103]
0 0 1 [100]
0 0 [104]
1 11 2
PS – estudos em Engenharia do Softaware são bastante difíceis, porque não conseguimos isolar as variáveis. Por exemplo, um resultado pode ter sido melhor para uma equipe do que para outra porque uma equipe tinha membros mais qualificados, ou o projeto não tinha tanta pressão, ou era de um domínio diferente etc, etc.
Neste caso é necessária que uma quantidade grande de estudos sejam feitos para que possamos ter um indicativo da eficácia da prática.
Mas fugindo um pouco da razão, não desenvolvo sem TDD nem a pau. :)
Estava pesquisando algo mais sobre TDD para ajudar a escrever o meu TCC, quando vi o seu post e adorei!
Com certeza ele estará no meio de uma das minhas referências! =)
Obrigada!