Concrete Logo
Hamburger button

O que eu aprendi em um mês de TDD

  • Blog
  • 26 de Maio de 2017

Este post foi originalmente publicado no Cocoa Academy (em inglês). Acesse aqui.

Por um longo período, eu programei sem escrever uma única linha de teste. Na verdade, eu pensava que escrever testes era uma perda de tempo até começar a trabalhar em uma empresa na qual eu deveria criar novos recursos para um aplicativo mal codificado. Toda vez que eu escrevia uma nova linha revisava o app centenas de vezes apenas para ter certeza que ainda estava funcionando e isso me fez perceber que testes são muito importantes, mas mesmo com isso em mente eu não dava o valor necessário.

Um dia meu colega de trabalho veio com uma ótima ideia: “vamos começar este novo projeto com um novo processo, vamos usar TDD”, ele disse. Mas o que diabos é TDD? Pois bem, é um processo de software que incentiva programadores a escrever testes antes de escrever código.

Test-driven development (TDD) é um processo de desenvolvimento de software que se baseia na repetição de um ciclo de desenvolvimento muito curto: requisitos são transformados em casos de teste muito específicos, então o software é escrito para passar apenas por aquele teste.

Até aquele momento eu não havia escrito muitos códigos de teste e eu sabia que aquela decisão ia me fazer sofrer (em uma boa maneira). Iria aprender sobre testes, novas libs, e o mais importante: como escrever um bom código de teste.

Por duas semanas fizemos pair programming para que eu pudesse me acostumar com o TDD e seu ciclo de vida, que é: você escreve um código de teste, executa e ele provavelmente vai falhar. Na verdade, ele deve falhar e agora você pode escrever algum código, mas apenas o mínimo para fazer o seu teste passar. Execute o teste novamente, e ele deve passar. Então, você pode escrever mais testes ou refatorar seu código anterior sem adicionar novos recursos.

Fonte: Agile Nutshell 

Neste desafio nós decidimos usar algumas libraries para nos ajudar a escrever testes no iOS. Vamos ver cada uma delas:

Quick

Define contextos para diferentes tipos de testes, beforeEach e o teste por si só. É útil  para deixar seus testes mais legíveis.

Nimble

Deixa suas asserções mais legíveis. Em vez de usar XCTAssertEqual(1+1,2,"expected one plus one equal two") você escreve expect(1+1) == 2 . Muito mais fácil.

Nimble-Snapshots

É uma ótima biblioteca, que ajuda muito quando falamos de testes unitários de UI. Ela tira uma screenshot da sua view e verifica se você não estragou tudo. Você pode gravar um snapshot usando expect(view) == recordSnapshot("screenshot-name") e depois ver se deu certo mudando recordSnapshot para snapshot, por exemplo, expect(view) == snapshot("screenshot-name")

KIF

É um framework que usamos para testar eventos de UI como um tap em um botão ou um scroll em uma UITableView.

Com todos esses testes e libraries, o que eu realmente aprendi com TDD?

Antes de tudo eu aprendi como escrever testes, de um parse no JSON até uma UIView, e isso é maravilhoso porque não preciso mais testar meu app um bilhão de vezes em um simulador (ou device) antes de lançar uma feature nova. Nossos testes unitários fazem isso por nós.

Segundo, eu me acostumei a escrever testes, e isso não é mais um monstro embaixo da cama. Na verdade, agora eu prefiro escrever testes antes do código e isso me fez escrever códigos melhores. Se você tem problemas em escrever testes provavelmente seu código está uma bagunça e você deveria refatorá-lo.

Este post é só o primeiro de uma série na qual vou mostrar como escrever testes usando Quick, Nimble, Snapshot e KIF desde um parse de JSON até ViewControllers, incluindo protocolos, tableviews e mais. Se você tem alguma sugestão ou está pensando em como escrever certos tipos de testes, deixe abaixo seu comentário que eu tento escrever em outro post. Até a próxima!

É desenvolvedor iOS e quer trabalhar em um time ágil  de verdade? Clique aqui!