🚀 TDD, Where Did It All Go Wrong (Ian Cooper)

Introdução

Visão Geral da Seção: Nesta seção introdutória, o palestrante faz uma breve apresentação e interage com a plateia. Ele destaca que não é mais inteligente ou mais esperto do que os demais e encoraja todos a contribuírem para a comunidade de desenvolvedores.

• O palestrante pergunta à plateia quantos já assistiram a um vídeo dele falando sobre o assunto.

• Ele questiona quantos estão praticando testes primeiro (test first) e mocks.

• Destaca que sua intenção é compartilhar ideias e encorajar outros a participarem de conferências para contribuir com a comunidade.

Sobre o Palestrante e Objetivos

Visão Geral da Seção: O palestrante fala sobre sua experiência como desenvolvedor e como decidiu compartilhar suas ideias através de palestras. Ele menciona que trabalha em uma empresa chamada Huddle, mas não está lá para fazer propaganda. Em seguida, ele apresenta os objetivos da apresentação.

• O palestrante explica que é apenas um desenvolvedor como qualquer outro, mas decidiu compartilhar suas ideias.

• Encoraja os participantes a se envolverem na comunidade de desenvolvedores para crescimento pessoal.

• Apresenta os objetivos da apresentação: discutir os problemas na prática de TDD, propor uma nova abordagem e falar sobre comportamento de equipe.

Problemas com a Prática de TDD

Visão Geral da Seção: O palestrante compartilha sua experiência ao longo dos anos praticando TDD e como percebeu problemas na forma como as pessoas estão praticando atualmente.

• Ele menciona que pratica TDD desde 2004 e que a comunidade dotnet em Londres foi uma das primeiras a adotar essa prática.

• Após praticar TDD por cerca de 10 anos, ele concluiu que havia problemas na forma como estavam fazendo.

• Destaca a importância de aprender com os erros e menciona que encontrou dificuldades ao manter testes extensos e caros.

Evolução da Compreensão do TDD

Visão Geral da Seção: O palestrante descreve como sua compreensão do TDD evoluiu ao longo dos anos.

• Ele explica que, inicialmente, estava convencido de que o TDD era a melhor prática e tentava convencer outros desenvolvedores disso.

• Mesmo desenvolvedores experientes resistiam à ideia do TDD, o que o levou a repetir constantemente os princípios básicos para tentar convencê-los.

Essa é uma visão geral das seções iniciais do vídeo.

Desenvolvimento de código com testes

Visão geral da seção: Nesta seção, o palestrante discute a importância do desenvolvimento de código com testes e os desafios associados a ele.

Testes em relação ao código de produção

• O palestrante menciona que eles estavam orgulhosos de ter produzido código que foi para produção com quase nenhum defeito.

• No entanto, ele percebeu que tinham cerca de três vezes mais código de teste do que código de produção.

• Ele questionou se isso estava correto e recorreu ao Twitter para obter respostas.

Obstáculos dos testes

• O palestrante destaca que muitas vezes havia pressão para pular os testes e lançar o código mais rapidamente.

• No entanto, eles argumentaram que escrever testes era parte integrante da prática de escrever bom código.

• Embora escrever testes tenha tornado o processo mais lento, eles acreditavam que era necessário para manter a qualidade do código.

Problemas com grandes conjuntos de testes

• O palestrante observa que, ao fazer alterações no código, muitas vezes eles acabavam quebrando vários testes.

• Isso ocorria especialmente quando faziam refatorações ou mudanças na organização do código.

• Os testes baseados em mocks eram particularmente problemáticos nesses casos.

Refatoração e problemas nos testes

• O palestrante esperava que os testes permitissem refatorar o código sem problemas.

• No entanto, descobriram que os testes frequentemente atrapalhavam as mudanças, exigindo esforço adicional para corrigir os testes quebrados.

Tendências contra o desenvolvimento orientado a testes

• O palestrante menciona que surgiram metodologias que desencorajavam o desenvolvimento orientado a testes.

• Algumas abordagens sugeriam lançar código sem testes e focar em obter feedback rápido dos clientes.

• Essas tendências questionavam a eficácia dos testes no processo de desenvolvimento.

Metodologias alternativas ao teste orientado

Visão geral da seção: Nesta seção, o palestrante discute algumas metodologias alternativas ao desenvolvimento orientado a testes.

Programação extrema (XP)

• A programação extrema propunha uma abordagem radical, onde apenas os desenvolvedores estariam envolvidos no processo.

• Eles escreveriam pequenos trechos de código chamados micro serviços, com cerca de 100 linhas cada.

• Essa abordagem não incluía testes, pois acreditava-se que o código seria tão simples que não haveria erros significativos.

Outras metodologias

• Além da programação extrema, outras metodologias como spike and stabilizer e lean software development também desencorajavam o uso de testes.

• Essas abordagens enfatizavam a interação direta com os clientes e a rápida iteração do produto.

Conclusão

O palestrante discute os desafios enfrentados ao implementar o desenvolvimento de código com testes. Embora reconheça as dificuldades e as tendências contrárias ao teste orientado, ele destaca a importância de manter a prática de escrever testes para garantir a qualidade do código.

O Programador Annoying

Visão Geral da Seção: Nesta seção, o palestrante fala sobre um programador chamado Bob que é considerado irritante pela equipe de engenharia, mas é adorado pelo time de negócios e produto por sua capacidade de entregar soluções rapidamente.

O Programador Bob

• Bob é um programador que entrega soluções rapidamente para a equipe de negócios e produto.

• A equipe de engenharia acha Bob irritante porque eles têm que gastar tempo mantendo e reescrevendo o código que ele escreve.

• Apesar das reclamações da equipe de engenharia, Bob ganha crédito por suas entregas rápidas e eficientes.

• Às vezes, os testes escritos pela equipe não são compreensíveis ou úteis, o que dificulta a manutenção do código.

• Muitos testes não fornecem informações relevantes ou não testam adequadamente o código real.

• Em alguns casos, os testes eram tão confusos ou inúteis que a melhor opção era excluí-los.

Testes Fitness

Visão Geral da Seção: Nesta seção, o palestrante discute os desafios enfrentados ao escrever testes fitness para demonstrar aos clientes que o software atende às especificações.

Testes Fitness

• Os testes fitness são escritos em linguagem natural para permitir que os clientes entendam as especificações do software.

• No entanto, escrever esses testes era um processo demorado e muitas vezes resultava em testes quebrados durante a implementação.

• Era difícil determinar se os testes estavam quebrados porque o código ainda não havia sido implementado ou se haviam erros no código.

• Os clientes raramente olhavam para esses testes fitness, tornando-os menos úteis como prova de funcionamento do software.

Complexidade dos Testes

Visão Geral da Seção: Nesta seção, o palestrante aborda a complexidade adicional dos testes fitness e como isso afetou o fluxo de trabalho dos desenvolvedores.

Complexidade dos Testes

• Além de passar nos testes de desenvolvimento, os desenvolvedores também precisavam executar todos os testes fitness antes de fazer check-in no código.

• Essa execução adicional de testes levava tempo e interrompia o fluxo de trabalho dos desenvolvedores.

• Muitas vezes, era necessário esperar enquanto os testes eram executados antes de continuar com o trabalho.

Essas são as principais informações extraídas do vídeo.

Ignorar testes e falta de valor percebido

Visão geral da seção: Nesta seção, o palestrante discute a falta de importância dada aos testes e a resistência dos desenvolvedores em escrevê-los.

Falta de preocupação com os testes

• Muitas vezes, os desenvolvedores ignoram os testes e continuam escrevendo código sem verificar sua funcionalidade.

• A existência de uma etapa no processo em que alguém é responsabilizado pelos testes falharem indica que ninguém realmente se importava com esses testes.

• Os desenvolvedores não viam valor nos testes e constantemente resistiam em escrevê-los.

Reações negativas ao TDD

• DHH expressou descontentamento com o TDD, afirmando que estava sendo forçado a fazer algo que não funcionava para ele.

• Kent Beck respondeu sarcasticamente às críticas de DHH sobre o TDD.

• Martin Fowler mediou um diálogo entre Kent Beck e DHH sobre suas opiniões divergentes sobre o TDD.

Onde o TDD foi errado?

Visão geral da seção: Nesta seção, o palestrante explora onde o TDD pode ter falhado e como corrigir seus problemas.

Reflexão sobre as práticas atuais do TDD

• É importante refletir sobre onde as práticas atuais do TDD podem ter se desviado do seu propósito original.

• Recomenda-se a leitura do livro "Test Driven Development: By Example" de Kent Beck para entender melhor o TDD.

• Muitas vezes, as pessoas aprendem sobre o TDD através de outras fontes e acabam seguindo práticas equivocadas.

Voltando às origens

• É necessário voltar ao início do TDD e compreender os fundamentos propostos por Kent Beck.

• O palestrante argumenta que o TDD tem respostas para os problemas enfrentados, mas muitas vezes essas respostas são ignoradas ou mal interpretadas.

Conclusão

Visão geral da seção: Nesta seção final, o palestrante conclui sua apresentação sobre o TDD.

• O palestrante encerra a apresentação reforçando a importância de compreender corretamente os princípios e fundamentos do TDD.

• Ele destaca que é possível corrigir os erros cometidos no uso do TDD e obter benefícios significativos com essa abordagem.

Importância de Test-Driven Development (TDD)

Visão Geral da Seção: Nesta seção, o palestrante discute a importância do Test-Driven Development (TDD) e como ele difere da abordagem tradicional de escrever testes após a implementação do código.

Entendendo o TDD

• O TDD é uma prática em que os testes são escritos antes da implementação do código.

• Ao praticar o TDD, é importante focar nos comportamentos esperados do software, não nos detalhes de implementação.

• O gatilho para escrever um novo teste no TDD é ter um requisito específico que você deseja implementar.

Testando a API do Software

• É essencial focar nos testes da API do software, ou seja, no contrato estável que o software oferece aos consumidores.

• A API representa a superfície exposta publicamente pelo módulo e deve ser testada em vez dos detalhes de implementação.

Escrevendo Testes para Requisitos

• Ao receber um requisito ou caso de uso, escreva testes para provar que pode atender a esse requisito.

• Use modelos como "given when then" para descrever as expectativas comportamentais do sistema sob teste.

Unidade de Teste vs. Módulo

• Antigamente, uma unidade de teste era considerada um teste de módulo.

• No entanto, essa definição mudou ao longo do tempo e agora muitas vezes se fixa apenas em classes e suas dependências.

• Focar apenas nas classes leva ao problema de criar testes altamente acoplados à implementação interna.

Testando a API do Software

Visão Geral da Seção: Nesta seção, o palestrante explica a importância de testar a API do software e esclarece o significado de "API" nesse contexto.

O que é uma API?

• Uma API representa o contrato estável que o software oferece aos consumidores.

• Não se refere apenas a APIs RESTful ou JSON, mas também à superfície publicamente exposta de um módulo.

Testando a Superfície Exposta

• Ao escrever testes, concentre-se naquilo que é oferecido pelo software aos consumidores.

• Teste as funcionalidades e comportamentos esperados, não os detalhes internos de implementação.

Unidade de Teste vs. Módulo

Visão Geral da Seção: Nesta seção, o palestrante discute a diferença entre uma unidade de teste e um módulo no contexto do TDD.

Definição Antiga vs. Nova

• Antigamente, uma unidade de teste era considerada um teste de módulo.

• No entanto, essa definição mudou ao longo do tempo e agora muitas vezes se fixa apenas em classes e suas dependências.

• Focar apenas nas classes leva ao problema de criar testes altamente acoplados à implementação interna.

Introdução ao TDD

Visão geral da seção: Nesta seção, o palestrante explica como chegar ao TDD e a importância de separar detalhes de implementação dos requisitos estáveis.

Entendendo o TDD

• O TDD (Test Driven Development) é uma abordagem para desenvolvimento de software que enfatiza a escrita de testes antes da implementação do código.

• O objetivo do TDD é testar os comportamentos do sistema, não apenas métodos individuais ou classes.

• É importante separar os detalhes de implementação dos requisitos estáveis para escrever testes eficazes.

Comportamento Orientado ao Desenvolvimento (BDD)

• O BDD (Behavior Driven Development) tem origem no TDD e enfatiza o desenvolvimento baseado em comportamentos.

• A mudança do termo "test" para "behavior" ajuda a evitar confusões e foca na demonstração dos comportamentos desejados no sistema.

Testando Comportamentos em vez de Métodos

• Ao praticar o TDD, é essencial focar nos comportamentos esperados pelo sistema, não apenas nos métodos individuais.

• Os testes devem refletir as necessidades dos consumidores externos do código, ajudando a definir uma API útil e usável.

• A unidade de isolamento nos testes é o próprio teste, não a classe sob teste. Isso significa que não é necessário isolar todas as dependências com mocks.

Teste de Comportamento vs. Teste Unitário

Visão geral da seção: Nesta seção, o palestrante diferencia entre teste de comportamento e teste unitário, esclarecendo a unidade de isolamento nos testes.

Teste de Comportamento

• O objetivo do TDD é testar os comportamentos do sistema.

• Os testes devem refletir as necessidades dos consumidores externos do código.

• Exemplo: Testar a adição de valores em diferentes moedas e converter o resultado com base nas taxas de câmbio.

Teste Unitário

• O termo "unidade" no contexto do TDD não se refere à classe sob teste, mas sim ao próprio teste.

• A unidade de isolamento nos testes é o próprio teste, não a classe sob teste.

• Não é necessário isolar todas as dependências com mocks para ter um teste adequado.

Foco na Usabilidade da API

Visão geral da seção: Nesta seção, o palestrante destaca a importância de considerar a usabilidade da API ao escrever testes.

Design da API

• Ao praticar o TDD, é importante considerar como a API do código seria útil para um consumidor externo.

• Os testes podem ser vistos como o primeiro consumidor do código, ajudando a definir como a API deve ser projetada e interagida.

Unidade de Isolamento nos Testes

• A unidade de isolamento nos testes é o próprio teste, não a classe sob teste.

• Não é necessário isolar todas as dependências com mocks para ter um teste adequado.

• Erros são frequentemente cometidos quando se confunde "unidade" com "classe sob teste".

Essas são as principais informações abordadas no vídeo, destacando a importância do TDD, a diferença entre teste de comportamento e teste unitário, e o foco na usabilidade da API ao escrever testes.

Prática de Testes Unitários

Visão Geral da Seção: Nesta seção, discute-se a prática de testes unitários e as razões por trás das escolhas feitas em relação à interação com bancos de dados e sistemas de arquivos.

Seleção e Isolamento dos Testes

• A seleção dos testes é baseada na necessidade de evitar impactos indesejados entre os testes.

• Ao tocar em um banco de dados, por exemplo, um teste pode afetar outro teste dependendo da ordem em que são executados.

• Para evitar esse problema, é necessário garantir o isolamento entre os testes.

• Uma abordagem comum é utilizar um banco de dados em memória ou fornecer um novo banco para cada teste.

Velocidade dos Testes

• A velocidade dos testes é essencial para fornecer feedback rápido aos desenvolvedores.

• Dependências pesadas podem tornar os testes lentos.

• Substituir essas dependências por versões mais rápidas pode ser uma solução viável.

Manutenção dos Testes

• Os testes devem ser fáceis de entender e manter.

• Ao focar nos métodos sendo testados, é importante descrever o comportamento esperado do método em vez de expor detalhes da implementação.

• O uso excessivo de mocks pode levar a acoplamento entre os testes e a implementação, dificultando as alterações futuras.

Fases do Desenvolvimento Orientado a Teste (TDD)

Visão Geral da Seção: Nesta seção, são apresentadas as fases do Desenvolvimento Orientado a Teste (TDD) e a importância de cada uma delas.

Fases do TDD

1. Red: Escrever um teste que falhe.

2. Green: Fazer o teste passar da maneira mais rápida possível, mesmo que seja necessário utilizar soluções temporárias.

3. Refactor: Melhorar o código sem alterar seu comportamento.

Importância das Fases

• A fase "Red" é fundamental para garantir que o teste realmente falhe na ausência de uma implementação correta.

• Durante a fase "Green", é permitido utilizar soluções rápidas, como copiar e colar código de fontes externas.

• A fase "Refactor" visa melhorar o código sem alterar seu comportamento, tornando-o mais legível e sustentável.

Abordagem para Implementação Rápida dos Testes

Visão Geral da Seção: Nesta seção, é discutida uma abordagem para implementar rapidamente os testes durante a fase "Green" do TDD.

Implementação Rápida dos Testes

• Durante a fase "Green", o objetivo é entender como resolver o problema e fazer com que o teste passe rapidamente.

• É recomendado escrever um script de transação simples, linha por linha, sem se preocupar com padrões ou classes complexas.

• O foco principal é obter um resultado correto e compreender como implementar os requisitos.

Com base no conteúdo do vídeo transcrito acima, essas são as informações relevantes fornecidas.

Escrevendo código ruim

Visão geral da seção: Nesta seção, o palestrante discute a importância de evitar escrever código ruim e como isso pode afetar negativamente o desenvolvimento de software.

Emular código ruim para ser rápido

• O palestrante menciona que às vezes as pessoas tendem a emular o código ruim de outros desenvolvedores para terminar mais rápido.

• É destacado que a velocidade muitas vezes é priorizada em relação ao design do código.

• Kent argumenta que é difícil fazer duas coisas ao mesmo tempo: entender a solução do problema e projetar o código. Isso pode levar a problemas como superengenharia ou análise paralisada.

A importância do código limpo

• O palestrante enfatiza a importância do código limpo e destaca que não deve haver "programação com fita adesiva".

• Refatoração é mencionada como uma etapa importante para produzir um código limpo.

• A remoção de duplicações é apontada como um dos principais impulsionadores da refatoração.

• Fowler's book sobre refatoração também é mencionado como uma referência útil.

Identificando padrões de design durante a refatoração

• Durante a etapa de refatoração, é possível identificar padrões de design adequados para melhorar o código.

• É recomendado procurar "cheiros" no código que indiquem melhores maneiras de fazer as coisas.

• Essa etapa é vista como uma oportunidade para pensar em usar padrões de design apropriados.

Refatoração sem escrever novos testes

• Durante a refatoração, não é necessário escrever novos testes.

• A refatoração é um processo de movimentos seguros que permitem alterar o design do código sem alterar seu comportamento.

• Os testes originais cobrem o comportamento esperado, mesmo que a implementação seja modificada.

Evitando acoplamento e dependências excessivas nos testes

• É importante evitar acoplar os testes aos detalhes de implementação.

• O foco deve estar no contrato público e estável da API, deixando os detalhes de implementação livres de testes.

• Evitar o uso excessivo de mocks pesados também é recomendado para facilitar a refatoração.

Benefícios da abordagem de refatoração

• A abordagem de refatoração permite escrever menos testes e avançar mais rapidamente no desenvolvimento.

• Ao evitar criar novas classes ou expor detalhes internos desnecessários, é possível manter-se atualizado com as práticas recomendadas pelos guias ágeis e gerentes.

Teste comportamental vs. teste de implementação

• É destacado que os testes devem se concentrar no comportamento esperado e não na implementação específica.

• Testar comportamentos em vez de implementações ajuda a evitar problemas ao refatorar o código.

Evitando tornar públicos detalhes desnecessários

• Não é necessário tornar públicos detalhes de implementação apenas para testá-los.

• É importante avaliar se esses detalhes são realmente parte do contrato do módulo ou apenas detalhes de implementação.

Conclusão

• A abordagem de refatoração, focada em código limpo e testes comportamentais, permite alterar a implementação sem quebrar os testes.

• Essa prática tem sido eficaz para o palestrante e sua equipe na busca por melhores maneiras de fazer as coisas.

Livro de Refatoração e Code Smells

Visão Geral da Seção: Nesta seção, é discutido o livro "Refactoring" de Martin Fowler, que aborda os code smells e fornece etapas seguras para refatorar o código.

Livro de Refatoração de Martin Fowler

• O livro "Refactoring" de Martin Fowler foi lançado antes do livro sobre TDD de Kent Beck.

• O livro aborda os code smells e fornece etapas seguras para refatorar o código.

• É importante entender que a refatoração não envolve mudanças na interface pública, mas sim na implementação interna do código.

Ferramentas para Refatoração

Visão Geral da Seção: Nesta seção, são discutidas as ferramentas DevExpress e ReSharper para refatoração.

Ferramentas DevExpress e ReSharper

• A DevExpress oferece um conjunto de ferramentas com um plugin para Visual Studio que permite a realização de refatorações.

• Inicialmente, a equipe da DevExpress não permitia a refatoração de métodos públicos em classes públicas, pois consideravam isso uma mudança e não uma refatoração.

• Posteriormente, eles adicionaram um botão chamado "unsafe refactoring", permitindo alterações em métodos públicos com base no conhecimento dos consumidores da API pública dentro da solução.

Conceito de Refatoração

Visão Geral da Seção: Nesta seção, é explicado o conceito fundamental da refatoração como uma alteração segura na implementação do código, sem afetar negativamente seu funcionamento.

Conceito de Refatoração

• A refatoração não envolve mudanças na interface pública, mas sim na forma como a implementação é realizada.

• É uma alteração segura e pequena no código, com receitas específicas para cada tipo de refatoração.

• As ferramentas automatizam as refatorações e garantem que o código não seja impactado negativamente.

Code Smells e Refatorações

Visão Geral da Seção: Nesta seção, são mencionados os code smells e como eles podem direcionar as etapas de refatoração.

Code Smells e Refatorações

• Os code smells são sinais de problemas no código que indicam a necessidade de refatoração.

• Alguns exemplos de code smells incluem duplicação de código, métodos muito longos ou classes com muitas responsabilidades.

• Durante o processo de refatoração, é possível extrair métodos ou até mesmo criar novas classes para melhorar a estrutura do código.

Padrões de Projeto e Refatorações

Visão Geral da Seção: Nesta seção, é discutida a relação entre padrões de projeto e refatorações.

Padrões de Projeto e Refatorações

• Muitas vezes, os desenvolvedores aplicam padrões de projeto incorretamente ou em contextos inadequados, tornando o software mais complexo do que necessário.

• A etapa ideal para aplicar padrões de projeto é durante a fase de refatoração, quando já se tem uma solução inicial e é possível identificar onde os padrões podem ser aplicados corretamente.

Testes Manuais e Automação

Visão Geral da Seção: Nesta seção, é discutida a importância da automação de testes em comparação com os testes manuais.

Testes Manuais e Automação

• Muitas organizações dependem fortemente de testes manuais antes de lançar o software, o que pode ser caro e não repetível.

• A automação dos testes é fundamental para reduzir custos e garantir a repetibilidade dos testes.

• Mudanças na interface do usuário podem afetar negativamente os testes automatizados, tornando-os frágeis e propensos a quebrar.

Hexagonal Architecture

Visão Geral da Seção: Nesta seção, é introduzida a arquitetura hexagonal como uma abordagem para melhorar os testes de integração.

Arquitetura Hexagonal

• A arquitetura hexagonal tem ganhado popularidade recentemente.

• Ela propõe que a maioria do código seja testada por meio de testes desenvolvidos pelos próprios desenvolvedores.

• Uma pequena quantidade de código deve ser dedicada aos testes das interfaces do usuário (UI), enquanto uma parte intermediária envolve os testes de integração entre as diferentes partes do sistema.

Entendendo a Arquitetura Hexagonal

Visão Geral da Seção: Nesta seção, o palestrante discute a arquitetura hexagonal e como ela lida com as preocupações tecnológicas.

Adaptadores de Tecnologia

• Os adaptadores de tecnologia são responsáveis por lidar com as preocupações tecnológicas externas à aplicação.

• Existem diferentes tipos de adaptadores, como adaptadores HTTP para comunicação web e adaptadores GUI para interfaces gráficas.

• Esses adaptadores se comunicam com o domínio da aplicação.

Camada de Portas

• A camada de portas é responsável por permitir a comunicação entre os diferentes componentes da aplicação.

• As portas funcionam como portas em um sistema operacional, permitindo que informações sejam transmitidas entre os componentes.

• É através das portas que os adaptadores se comunicam com o código do domínio.

Testes na Camada de Portas

• Os testes devem ser direcionados à camada de portas, não aos detalhes internos da implementação.

• Os testes na camada de portas garantem que a comunicação entre os componentes esteja correta e que eventos ou alterações no banco de dados ocorram adequadamente.

Tipos de Teste

• Os testes de integração verificam se é possível chamar corretamente o código do domínio através dos adaptadores configurados corretamente.

• Os testes do sistema verificam se é possível chamar a aplicação como um todo, do ponto de vista externo.

• É importante escolher o tipo de teste adequado para cada situação.

TDD e Refatoração

• O TDD (Desenvolvimento Orientado a Testes) pode ser usado para entender como algo funciona e refinar a implementação.

• O TDD pode ser dividido em diferentes "marchas" ou níveis, dependendo do grau de detalhamento necessário.

• É importante encontrar um equilíbrio entre escrever testes suficientes e evitar escrever código especulativo desnecessário.

ATP

• A prática do ATP (Teste de Programador) tem suas vantagens e desvantagens.

• Alguns argumentam que os clientes não se importam com os testes ATP e que eles podem se tornar uma carga de manutenção significativa.

• Outros defendem que os testes ATP ajudam a manter os desenvolvedores honestos e fornecem uma visão mais completa do sistema.

Introdução ao Teste de Comportamento

Visão Geral da Seção: Nesta seção, o palestrante discute a importância do teste de comportamento e como ele difere dos testes tradicionais. Ele também aborda o uso excessivo de objetos mock e containers IOC.

Teste de Comportamento

• O teste de comportamento é uma metodologia ágil que enfatiza a importância de testar o comportamento do software em vez dos métodos e classes individuais.

• Evite usar objetos mock para isolar classes, pois isso acopla seus testes ao software e dificulta as alterações futuras.

• Containers IOC (Inversão de Controle) são frequentemente usados em excesso. Eles devem ser usados apenas quando exigidos pelo framework, caso contrário, é preferível usar factories para criar objetos.

• Evite também o uso excessivo de ORM (Mapeamento Objeto-Relacional), assim como os containers IOC.

Resumo Rápido

• Teste o comportamento do software em vez dos detalhes internos.

• Adicione testes de integração apenas para verificar a implementação das interfaces externas.

• Evite usar mocks para isolar classes internas ou adaptadores.

Para mais informações sobre esse assunto, recomenda-se assistir à gravação completa da palestra online.