Implementando TDD no iOS com Swift

Quando a plataforma iOS dava seus primeiros passos, as aplicações eram pequenas, simples e essencialmente single threaded, ou seja, executavam sobre uma única thread por vez. Em se tratando de concepção estrutural, tais aplicativos não apresentavam grandes desafios para os desenvolvedores e, sobretudo, para os testadores, que dispunham de poucos fluxos de teste complicados, o que garantia ciclos de testes mais rápidos e concisos. Hoje, a Apple Store evoluiu de modo a abraçar um universo enorme de exigências que o mercado cada vez mais solicitava, forçando a tecnologia do iOS (hoje completamente representada por seus principais frameworks, como o Swift) a evoluir de igual forma.

Com o advento dos testes unitários e das novas boas práticas adotadas pelos demais desenvolvedores do universo web e desktop, os testes unitários se fazem necessários para assegurar o bom funcionamento do código de negócio uma vez implementado e evoluído na aplicação. Evoluir código é, hoje, uma prática totalmente associada ao uso de testes ao longo do ciclo de vida do software, sendo extremamente necessário o bom conhecimento de tais práticas por parte do time como um todo: tanto desenvolvedores, que terão de assegurar uma boa cobertura das regras implementadas, quanto dos profissionais de qualidade, que garantirão o correto funcionamento das mesmas.

Em vista disso, este artigo visa expor os principais conceitos relacionados ao TDD (Test-Driven Development), focando no universo do desenvolvimento para iOS e explorando as melhores formas de codificar, escrevendo os testes antes mesmo de implementar qualquer linha de código.

TDD + Xcode

Em 1998, a companhia suíça Sen:te desenvolveu um dos primeiros frameworks de teste para o Objective-C: o OCUnit. Com a chegada do Xcode 2.1, a Apple adicionou o OCUnit ao Xcode. Uma das razões para isso foi que a mesma Apple o usou para desenvolver o Core Data (o framework de persistência e grafos oficial do OS X) ao mesmo tempo em que desenvolviam o Tiger, o OS com o qual o Core Data seria empacotado e vendido.

A Apple percebeu o quão valiosos os testes de unidade podem ser quando se trata do desenvolvimento de sistemas complexos em ambientes de constante mudança. Em vista disso, após a inclusão do framework de testes ao Xcode, foi possível medir a considerável queda no tempo total necessário para iniciar a criação dos testes unitários e, como consequência, mais pessoas começaram a escrevê-los, findando numa importante quebra de paradigma. Ao mesmo tempo, eles queriam que os desenvolvedores da comunidade como um todo também se beneficiassem dos testes unitários.

Em 2008, o OCUnit foi integrado ao iPhone SDK 2.2 para permitir testes unitários de aplicativos para iPhone. Quatro anos mais tarde, foi renomeado para XCUnit (XC significa Xcode).

Finalmente, em 2013, o teste de unidade tornou-se um cidadão de primeira classe no Xcode 5 com a introdução do XCTest. Com o XCTest, a Apple adicionou elementos de interface do usuário específicos para Xcode, o que permitiu a execução de testes específicos, encontrando falhas mais rapidamente, além de permitir uma visão geral dos testes como um todo.

TDD Workflows – red, green e refactor

O TDD abrange três passos básicos em seu workflow (fluxo de execução):

• Red: nesse ciclo, começamos escrevendo um teste falho. Ele precisa essencialmente testar uma funcionalidade obrigatória do software que ainda não está implementada ou um caso de exceção que queremos ter certeza de que será coberto. O nome “red” (vermelho) vem do fato de a maior parte dos frameworks indicar um teste falho através dessa cor. É muito importante que o teste escrito nesse passo falhe, caso contrário corremos o risco de estar implementando um teste que sempre passa, independente dos parâmetros que passemos para ele, sendo assim inútil. Ainda pode ser possível que a funcionalidade já esteja implementada. Em ambos os casos, muita atenção na hora de implementá-los.
• Green: nesse passo precisamos escrever o código o mais simples possível, o suficiente para passar no teste. Não importa se o código recém-escrito é bom ou não (pode ser inútil e até mesmo errado), o importante é fazer com que todos os testes passem. O nome “green” (verde) se refere a como a maioria dos frameworks identifica um teste que passou. É muito importante escrever o código o mais simplista possível para fazer o teste passar, pois através disso seremos capazes de escrever o código que de fato precisamos.
• Refactor: durante o passo green, escrevemos código suficiente para ter os testes funcionando e, como vimos, não importa se código está feio e errado. No passo “refactor” (refatoração), iremos melhorar o código, removendo duplicações, extraindo valores em comum, etc. Faça nesse passo o que for preciso para tornar o código o melhor possível. Os testes te ajudarão a não quebrar as funcionalidades já implementadas enquanto estiver refatorando o código."
  [...] continue lendo...