Artigos Mobile Implementando TDD no iOS com Swift
Por que eu devo ler este artigo:Este artigo se mostra muito útil para desenvolvedores que lidam com o desenvolvimento de aplicativos móveis e precisam melhorar suas habilidades no que se refere à criação e manutenção de testes unitários no universo iOS. Mais que isso, o artigo propõe uma abordagem completa sobre o TDD, bem como suas aplicabilidades, prós, contras, etc. Neste artigo você verá, através de alguns exemplos práticos e simples, os principais conceitos aplicados na ferramenta de desenvolvimento Xcode, entendendo como manipular seus testes desde a criação, análise de erros, correção, etc.

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 el ...

    Fim do trecho gratuito • continue abaixo
    CONTEÚDO EXCLUSIVO

    Desbloqueie toda a DevMedia

    • +2000 artigos e vídeos
    • +40 trilhas sobre Front-end, Back-end, IA e muito mais
    • +5000 exercícios práticos
    • Mentorias ao vivo individuais
    até 50% OFF
    A partir de
    R$ 69 /mês
    Assinar agora