Testando software

Inviável

Entregar software robusto e com boa qualidade já é, por si só, uma suadeira imensa. Manter esse mesmo código funcionando com o passar do tempo, mesmo com a interferência de outras funcionalidades, a evolução da infraestrutura e das bibliotecas de que depende é trabalho que, levado à risca, tornaria os feitos de Hércules meras brincadeiras de um praticante de crossfit grego. Nós precisamos de ferramentas que ajudem a botar rédeas nesse problema.

Uma das mais simples e mais transformadoras é o uso de testes automatizados: código que verifica código, consistente e repetidamente, sem preconceitos, sem cansaço, sem passado ou futuro, fazendo o que computadores fazem melhor. Com a ajuda de práticas bem estabelecidas (e tendo em mente que o mais importante é reduzir risco/gerar valor para o negócio), conseguimos criar software mais robusto, mais bem projetado e com alguma referência do que é desejável para nos proteger de regressões. Dos testes automatizados nascem as benfazejas práticas de refactoring e Continuous Integration; dele brota aquela calma de quem toma uma xícara de chá olhando para um campo verdejante numa manhã fria de outono.

Vem com a gente, que este é o Inviável 19.

• Test-Driven Development
• Test-Driven Development na wiki do c2
• Unit testing
• Detroit School TDD
• London School TDD
• “I get paid to write code that works, not for tests”
• Property-based testing: what is it?
• QuickCheck
• Property-based testing in Ruby (Blog do Vitor)
• Mocks Aren’t Stubs
• Unit Testing is Design
• Refactoring
• Functional Core, Imperative Shell
• Boundaries
• How to sell software testing

Recomendações:

• Leonardo:
  • Altered Carbon
  • Celeste
  • Matt Makes Games
• Vitor:
  • PouchDB
  • CouchDB
  • “Growing Object-Oriented Software, Guided By Tests”, Nat Pryce e Steve Freeman
  • Langsam gesprochene Nachrichten