VIDEO
HIGHLIGHT
Log InSign up
🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
SummaryTranscriptChat

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

Introduction and Audience Engagement

The speaker asks the audience if they have seen a video of his talk before, and mentions that there are some nuances in giving it live. He also asks how many people are currently using test-first or mocking techniques.

  • Some audience members have seen a video of the talk before.
  • The speaker acknowledges that there may be differences between watching a video and attending the live talk.
  • The speaker asks how many people are currently using test-first or mocking techniques.
  • A few audience members indicate that they use test-first, while others use mocking techniques.

Encouragement to Contribute to the Community

The speaker emphasizes that conference speakers are not necessarily smarter or cleverer than the audience. He encourages everyone to participate in conferences and contribute back to the community.

  • Conference speakers are not inherently more intelligent than the audience.
  • The speaker encourages attendees to consider speaking at conferences as a way to give back to the community.
  • Speaking at conferences can lead to personal growth for developers in terms of expressing ideas more clearly.

Personal Experience with TDD

The speaker shares his background as a developer who decided to share his ideas through speaking engagements. He mentions being forced into it due to limited experts in reverse engineering when .NET first started. He encourages attendees to get involved in meet-ups and user groups for personal growth.

  • The speaker is just a developer like the audience, sharing ideas with others.
  • Limited experts in reverse engineering led him to start speaking at meet-ups and user groups.
  • Getting involved in such communities can lead to personal growth for developers.

Sharing Ideas Based on Experience

The speaker clarifies that he has nothing to sell and is sharing ideas based on his experience. He mentions that some of the ideas discussed may be specific to his company but are not intended as a marketing pitch.

  • The speaker's ideas are based on his own experience, not a sales pitch.
  • Some ideas may be specific to his company, but the intention is not to market anything.
  • Attendees cannot buy the speaker's services.

Agenda for the Talk

The speaker outlines the agenda for the talk, which includes discussing problems with current TDD practices, rebooting TDD practice, exploring concepts like red-green-refactor, examining mistakes in TDD practice, and discussing team behavior.

  • The talk will address problems with current TDD practices.
  • Rebooting TDD practice will involve revisiting concepts like red-green-refactor.
  • Mistakes in TDD practice will be examined.
  • Team behavior and dynamics will also be discussed.

Experience with TDD since 2004

The speaker shares his experience practicing TDD since 2004 in London. He mentions early adoption by the .NET community due to close relationships with an XP group. This talk was first given in 2013 after approximately 10 years of practicing TDD.

  • The speaker has been practicing TDD since 2004 in London.
  • Early adoption of TDD by the .NET community was influenced by close relationships with an XP group.
  • This particular talk was first given in 2013 after approximately 10 years of practicing TDD.

Evolving Understanding of TDD

The speaker discusses how his understanding of TDD has evolved over time. He mentions encountering difficulties and expenses in maintaining extensive test suites.

  • The speaker's understanding of TDD has evolved over time.
  • Difficulties and expenses in maintaining extensive test suites have been encountered.

Resistance to TDD

The speaker recalls facing resistance from others when advocating for TDD. Despite smart developers expressing skepticism, he continued to promote the benefits of TDD.

  • The speaker faced resistance when advocating for TDD.
  • Smart developers expressed skepticism about the benefits of TDD.
  • The speaker persisted in promoting the benefits of TDD despite the resistance.

Desenvolvimento Orientado a Testes (TDD)

Esta seção aborda o Desenvolvimento Orientado a Testes (TDD) e sua aplicação no desenvolvimento de software. O palestrante compartilha sua experiência com TDD, discute a importância da camada de portas e adaptadores, e destaca os benefícios do TDD na identificação de problemas.

A importância da camada de portas e adaptadores

  • O palestrante destaca que é importante ter uma camada de portas e adaptadores em um sistema.
  • Frameworks como Django, Sinatra e Web API são mencionados como exemplos dessa camada.
  • A comunidade .NET em Londres foi pioneira na adoção do TDD e na utilização da camada de portas para persistência de dados.
  • A comunicação entre diferentes sistemas era feita por meio do envio de mensagens usando RabbitMQ.

Benefícios do TDD na identificação de problemas

  • O palestrante pratica TDD desde 2004 e destaca que o processo permite identificar erros no código mais facilmente.
  • Ao utilizar uma camada de porta, é possível encontrar falhas no código ao testar as interações com essa camada.
  • O uso extensivo de testes ajuda a descobrir problemas relacionados ao banco de dados ou eventos.

Integração dos testes com o desenvolvimento

  • Os testes devem ser integrados ao processo de desenvolvimento.
  • O palestrante menciona a resistência inicial encontrada ao introduzir TDD em projetos com código de terceiros.
  • A prática do TDD permite verificar se as chamadas corretas estão sendo feitas e ajuda a identificar problemas.

Conclusão

Esta seção conclui a palestra sobre Desenvolvimento Orientado a Testes (TDD), destacando a importância da camada de portas e adaptadores, bem como os benefícios do TDD na identificação de problemas no código.

Pontos principais

  • A utilização de uma camada de portas e adaptadores é fundamental para facilitar o teste e identificação de erros no código.
  • O TDD permite descobrir problemas mais facilmente ao testar as interações com essa camada.
  • A integração dos testes com o desenvolvimento é essencial para garantir a qualidade do software.

Desenvolvimento de Testes

Neste trecho, o palestrante discute a importância do desenvolvimento de testes e como isso pode afetar o processo de desenvolvimento de software.

A importância dos testes

  • O palestrante destaca que é importante realizar testes no código para garantir sua qualidade.
  • Ele menciona que tiveram três vezes mais problemas quando não realizaram os testes adequadamente.
  • Uma das razões para fazer os testes é evitar problemas no código em produção.
  • O palestrante menciona que foi ao Twitter buscar respostas sobre a importância dos testes e encontrou um livro que defendia essa prática.
  • Ele argumenta que os testes ajudam a manter os desenvolvedores honestos na escrita do código.

Benefícios dos testes

  • O autor James Shaw afirma que ter uma quantidade adequada de código de teste ajuda no desenvolvimento mais rápido e eficiente.
  • Os clientes muitas vezes não se importam com os testes, mas eles são essenciais para evitar problemas futuros.
  • Embora escrever todos os testes unitários possa levar tempo, eles são necessários para garantir a qualidade do software.
  • Com o tempo, percebeu-se que os testes eram importantes para resolver problemas relacionados à prática do desenvolvimento.

Desafios dos grandes conjuntos de teste

  • O palestrante menciona que, ao lidar com grandes conjuntos de testes, qualquer mudança pode quebrar muitos testes.
  • A tradução entre a linguagem natural e o código pode ser um desafio ao escrever os testes.

Prática do Desenvolvimento

Nesta parte da palestra, o foco é na prática do desenvolvimento de software e como isso se relaciona com os testes.

Prática do TDD

  • O palestrante destaca a importância da prática do Test Driven Development (TDD).
  • Ele menciona que o TDD ajuda a definir comportamentos antes de escrever o código.
  • A prática do TDD permite uma abordagem mais orientada a comportamento no desenvolvimento de software.

Benefícios do TDD

  • O palestrante afirma que o TDD ajuda a evitar problemas futuros no código.
  • Ele menciona que o TDD permite uma melhor compreensão dos requisitos e comportamentos esperados.
  • A prática do TDD também ajuda na refatoração e melhoria contínua do código.

Desafios da adoção do TDD

  • O palestrante reconhece que adotar o TDD pode ser desafiador para alguns desenvolvedores.
  • Ele destaca que é necessário um esforço inicial para aprender e praticar o TDD corretamente.
  • O TDD pode exigir uma mudança de mentalidade e abordagem no desenvolvimento de software.

Conclusão

Nesta parte final da palestra, o palestrante faz uma conclusão sobre a importância dos testes e do TDD no desenvolvimento de software.

  • O palestrante reforça a importância dos testes para garantir a qualidade do código.
  • Ele destaca que o TDD é uma prática valiosa para orientar o desenvolvimento de software.
  • O palestrante encoraja os desenvolvedores a adotarem os testes e o TDD como parte integrante do processo de desenvolvimento.

Desenvolvimento Ágil e Metodologia XP - Portuguese

This section discusses the benefits of full-scale agile methodology and test-driven development, as well as the potential slowdown caused by excessive documentation.

Full-Scale Agile Methodology and Test-Driven Development

  • Full-scale agile methodology is worth developing because it promotes test-driven development.

Potential Slowdown in Development

  • Excessive documentation can slow down the development process.

Importance of Collaboration and Communication

  • Collaboration and communication are essential in software development.
  • Developers should engage with colleagues from different roles, including QA and product teams.
  • Conversations between developers and customers can provide valuable insights.

Microservices Architecture

  • Kent Beck, DHH, and Martin Fowler have discussed microservices architecture.
  • Microservices involve writing small pieces of code that communicate with each other.

The transcript provided only covers a small portion of the video, so these notes may not capture the full context or content of the entire video.

Video description

🗓️ Upcoming developer events: https://dev.events Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of Kent's original rules so that TDD practice bears little resemblance to Kent's original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the 'public interface' have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk, we re-discover Kent's original proposition, discover where key misunderstandings occurred and look at a better approach to TDD that supports software development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written.