Pontos Principais
- Nos testes de software modernos, os desenvolvedores estão cada vez mais responsáveis por escrever testes para seus códigos e para o código de seus pares.
- O medo do fracasso ou a "ansiedade de avaliação" é uma condição psicológica muito comum que é diretamente afetada pelo auto-teste e pelo teste em equipe.
- A abordagem rigorosa de testar-se tudo, abordada no TDD, pode ser considerada de certa forma um mecanismo de defesa para desenvolvedores que procuram evitar críticas de seu código.
- Novas abordagens, como Behavior Driven Development (BDD), podem aliviar essa ansiedade e fazer com que as equipes assumam a responsabilidade pelo fracasso juntos.
- É necessária uma medida mais ampla de cobertura de código que irá mudar o foco em falhas no código de um desenvolvedor, para que uma equipe seja capaz de atender aos requisitos do cliente .
Nunca vou escrever um teste, esse não é o meu trabalho como programador.
Esta foi a declaração de despedida de um desenvolvedor que decidiu abandonar o cargo, dois dias depois que o líder da equipe anunciou a adoção do TDD para lidar com problemas sérios de qualidade de código que ele descobriu. Foi em 2006, e esse líder da equipe foi o proeminente desenvolvedor e testador Jeff Langr, que compartilha a história em seu prefácio para o livro "Developer Testing", publicado pela Addison Wesley. Langr diz:
Felizmente, 10 anos depois, a maioria dos desenvolvedores aprendeu que é realmente seu trabalho testar seu próprio código. Poucos de nós iremos participar de uma entrevista onde alguma forma de teste de desenvolvimento não será discutida. A expectativa é que, sendo você uma pessoa profissional de desenvolvimento de software, torna-se parte de seu trabalho elaborar um produto de alta qualidade. Dez anos depois, excluo qualquer pretensão de contratação de alguém que pensou que não é necessário testar seu próprio código.
Na era do desenvolvimento ágil e do DevOps, desenvolvedores são cada vez mais obrigados a assumir a responsabilidade por todos os aspectos de seu código: desde a qualidade até a manutenção, implantação, escalabilidade e segurança. Muitas pessoas tem escrito sobre os aspectos culturais dessa enorme mudança: do programador como "técnico de código" ao programador como um membro holístico de uma organização que deveria oferecer valor aos clientes.
Neste artigo, nos concentraremos em um aspecto específico dessa mudança: o impacto emocional do programador como testador.
Uma coisa é ser responsável por tornar seu código disponível para produção. Outra é testar e descobrir problemas sérios em seu código, ter que admitir esses problemas, corrigi-los e fazer o commit de forma transparente a uma base de código compartilhada.
Por exemplo, considere a prática comum em equipes ágeis de exibir um alerta em uma grande tela, ou até mesmo tocar uma sirene, quando alguém "quebra o build", deixando visível quem causou o erro. Inevitavelmente, a maioria dos desenvolvedores que passam por isso serão afetados emocionalmente.
Testes de desenvolvedor como "ansiedade de avaliação"
O teste está se tornando uma atividade introspectiva e avaliadora. Desenvolvedores estão testando regularmente seu próprio trabalho. Colegas próximos e superiores testam seu trabalho. Existem revisões periódicas de código que expõem falhas em seu trabalho.
Claro, sempre houve equipes de QA criticando a atividade do desenvolvedor. Mas eles fazem isso de fora, freqüentemente em um paradigma de "caixa preta". E os testadores de QA foram, pelo menos no passado, tratados como empregados de nível inferior, com salários mais baixos, às vezes terceirizados, reduzindo o impacto dessa crítica.
Vindo de um desenvolvedor, que é mais alto na cadeia alimentar organizacional e entende o código, a crítica pode prejudicar muito mais.
A ansiedade é a forma mais comum de doença mental nos EUA, afetando 18,1% da população. Um tipo comum de ansiedade é "Ansiedade social e de avaliação", que é a terceira maior desordem psicológica do país. É definido como "Medo de ser julgado e avaliado negativamente por outras pessoas, levando a sentimentos de inadequação, constrangimento, humilhação e depressão". Ou, em português claro: medo do fracasso. De acordo com o terapeuta de ansiedade Thomas A. Richards:
Se o seu terapeuta disser: "enfrente seus medos e eles irão embora", ele não entendem a dinâmica da ansiedade social. Nós sempre enfrentamos nossos medos desde o nascimento, e ainda assim nos sentimos mais temerosos do que o que fizemos no passado.
Não estamos tentando sugerir que as práticas de testes podem levar a um transtorno de ansiedade completo (exceto, talvez, em alguns casos extremos). Mas parece provável que muitos, se não a maioria, dos programadores que participam de práticas modernas de testes ágeis, estão enfrentando esse medo de avaliação social negativa.
Essa ansiedade afeta o bem-estar dos desenvolvedores, afetando negativamente sua produtividade e, a longo prazo, diminui o desenvolvimento profissional.
Test-Driven Development (TDD) : Um mecanismo de defesa inconsciente?
Foi iniciada uma discussão sobre a validade e a necessidade do TDD no desenvolvimento ágil. O TDD é uma abordagem rigorosa resumida como "vermelho/verde/refatorar", no qual o desenvolvimento de qualquer unidade de software deve começar com um teste avaliando essa unidade, que inicialmente falha, seguida da funcionalidade que fará com que esse teste seja aprovado. Posteriormente, uma refatoração deve garantir que o teste continue a passar.
Já em 2014, críticas proeminentes foram ouvidas, destacando-se que o TDD estava morto. David Heinemeier Hansson, um crítico vocal, escreveu que o TDD prometia um nirvana de código claro e previsível, mas na realidade, tornou-se um evangelho que os desenvolvedores são obrigados a seguir mesmo quando causa efeitos negativos:
Ao longo dos anos, a prática do test-first tornou-se cada vez mais agressiva. Mais malvada. E às vezes eu fui sugado para o lado fundamentalista, sentindo-me mal por não seguir o verdadeiro evangelho. (...) Em público, na melhor das hipóteses, mencionei não fazer o test-first o tempo todo e, na pior das hipóteses, continuei a apoiar a prática como "o caminho certo". Agora, lamento isso.
Talvez fosse necessário usar o TDD de forma contra-intuitiva para quebrar a falta de testes de regressão automatizados da indústria. (...), mas há muito tempo mudei o dogma de design. Eu sugiro que você dê uma olhada no que essa abordagem está fazendo para a integridade do seu projeto (ênfase adicionada, G.D.M).
A atual experiência fanática do TDD leva a um foco primário em testes de unidade (...) Eu não acho que isso seja saudável. As unidades de teste conduzem a uma rede excessivamente complexa de objetos intermediários e indiretos (...) É dada a luz para algumas monstruosidades verdadeiramente horríveis da arquitetura. Uma densa selva de objetos de serviço e padrões de controle .
É fácil notar que a maioria das organizações tem se afastado do TDD como um paradigma de teste e migrado para o Behavioral Driven Development (BDD). Heather Krebsbach, da Atlassian, escreveu inequivocamente em 2016:
"Esta abordagem de test-first se tornou cada vez mais popular e foi nomeada como desenvolvimento orientado por teste (TDD), mas as empresas rapidamente perceberam que não lhes daria a visibilidade e a cobertura que precisavam para os casos comerciais mais importantes em seus sistemas. Assim, uma variante de TDD nasceu, conhecida como (BDD) Behavioral Driven Development (em português Desenvolvimento Orientado pelo Comportamento), com foco no comportamento do sistema em vez de suas especificações técnicas.
Esta é uma curta descrição do porquê "TDD não funciona", mas gostaríamos de cavar um pouco mais fundo. Utilizar a descrição de David Hansson de uma prática "fanática" e às vezes irracional, combinada com a descrição de Krebsbach de TDD como ineficaz, evoca o conceito psicológico de intelectualização. De acordo com a Wikipedia:
Na psicologia, a intelectualização é um mecanismo de defesa onde o raciocínio é usado para bloquear o confronto com um conflito inconsciente e seu estresse emocional - onde o pensamento é usado para evitar o sentimento. Isso envolve a remoção de sua própria emoção no caso de um evento estressante. A intelectualização é diferente da racionalização que é a justificativa pseudo-racional de atos irracionais.
Poderia ser que a prática do teste "compulsivo", de cada uma das linhas de código como sugerido pelo TDD, inconscientemente um mecanismo para proteger os desenvolvedores contra as críticas nesse código?
Esta é uma declaração forte, e não estamos sugerindo que TDD seja apenas isso. Estamos sugerindo que este lado emocional está dentro da metodologia e pode ser a causa de sua natureza intransigente, dogmática e às vezes míope.
O BDD é uma abordagem emocionalmente mais saudável?
O BDD é melhor que o TDD? Neste contexto, pode ser. Behavioral Driven Development concentra-se em requisitos de negócios e não em código. Especifica uma "história" ágil em linguagem formal e permite que equipes de desenvolvimento avaliem essa história.
Isso nos tira de um exercício de código de teste escrito por um desenvolvedor específico e uma busca pelo desenvolvedor que "quebrou a compilação", e nos leva para um exercício mais amplo que avalia o desempenho de uma equipe inteira.
Afinal, uma equipe ágil compartilha a responsabilidade pelo valor entregue aos clientes e reconhece-se que o valor é um esforço de equipe entre desenvolvedores, testadores e administradores de sistemas. No BDD, testar a história, em vez de a unidade de código, tira o "calor" dos desenvolvedores individuais e se torna uma atividade introspectiva do grupo, bem como a "retrospectiva do scrum", que é feita em conjunto como equipe.
Posicionamos que enquanto TDD era, pelo menos em parte, um mecanismo defensivo que permitia a cada desenvolvedor justificar seu próprio código, o BDD é uma abordagem mais saudável. Ele permite aos desenvolvedores avaliar seu trabalho como equipe e compartilhar a responsabilidade pelas falhas encontradas, abordando e facilitando a ansiedade, ao invés de apenas intelectualizá-la.
Rumo a um conceito mais amplo de cobertura de teste
A SeaLights, uma startup focada em ajudar as equipes ágeis a aumentar a cobertura do teste, defende que as métricas de teste no mundo do desenvolvimento ágil de hoje são muitas vezes distorcidas (aviso: eu sou um conselheiro da SeaLights). A "cobertura de teste / código", uma métrica muito cobiçada, é quase sempre considerada como "cobertura de teste unitário". Isso parece ser um retrocesso à era do TDD, em que o teste unitário foi considerado a parte primária e mais importante do teste ágil.
Em uma metodologia BDD, os testes são mais amplos e inclusivos, mas as métricas de teste não evoluíram de acordo. As equipes estão aumentando o uso de testes automatizados de UI, testes de integração e aceitação - mas continuam a medir a "cobertura" como uma porcentagem do seu código coberto por testes unitários.
A cobertura do teste de unidade não é uma medida verdadeira de como os conjuntos de testes abrangentes são, em um mundo BDD, nem é uma métrica para o gerenciamento avaliar a eficácia de um teste.
É necessária uma medida de cobertura de código, que também leve em consideração testes de Integração, de UI e testes de aceitação. Em vez do impulso um tanto compulsivo para testar cada linha de código, as equipes devem avançar para garantir que todas as funções ou "história" cobertas pelas equipes ágeis sejam testadas.
Medir essa cobertura holística e trabalhar juntos para alcançá-la será uma maneira verdadeira de reduzir a ansiedade dos desenvolvedores. Isso pode ajudar a enfrentar falhas no nosso código em conjunto, em vez de tentar intelectualizá-los, evitá-los ou justificá-los.
Sobre o Autor
Gilad David Maayan é um escritor de tecnologia que ajuda as principais marcas de tecnologia a elucidar seus produtos para novos públicos. Ele também é CEO e fundador do Agile SEO, que reúne desenvolvedores, liderança de TI e possui conteúdo relevante através dos motores de busca.