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.
TDD: Prós e Contras
Vejamos algumas das vantagens mais aparentes do TDD:
- Você só escreve o código que é
necessário: Seguindo as
regras do TDD, precisamos parar ...
Quer ler esse conteúdo completo? Tenha acesso completo
Confira outros conteúdos:
Perguntas frequentes
Quem somos?Por que a programação se tornou a profissão mais promissora da atualidade?Como faço para começar a estudar?Em quanto tempo de estudo vou me tornar um programador?Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!O que eu irei aprender estudando pela DevMedia?Principais diferenciais da DevMediaQual o investimento financeiro que preciso fazer para me tornar um programador?Como funciona a forma de pagamento da DevMedia?Por Fabricio Em 2016Nossos casos de sucesso
Eu sabia pouquíssimas coisas de programação antes de começar a estudar com vocês, fui me especializando em várias áreas e ferramentas que tinham na plataforma, e com essa bagagem consegui um estágio logo no início do meu primeiro período na faculdade.
Estudo aqui na Dev desde o meio do ano passado! Nesse período a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta é continuar estudando e praticando para ser um Full-Stack Dev!Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma é bem intuitiva e muuuuito didática a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!
Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda não tinha visto. A didática é do jeito que qualquer pessoa consegue aprender. Sério, to apaixonado, adorando demais.
Adquiri o curso de vocês e logo percebi que são os melhores do Brasil. É um passo a passo incrível. Só não aprende quem não quer. Foi o melhor investimento da minha vida!
Foi um dos melhores investimentos que já fiz na vida e tenho aprendido bastante com a plataforma. Vocês estão fazendo parte da minha jornada nesse mundo da programação, irei assinar meu contrato como programador graças a plataforma.
Wanderson Oliveira
Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exercícios práticos que não tem como não aprender, estão de parabéns!
Obrigado DevMedia, nunca presenciei uma plataforma de ensino tão presente na vida acadêmica de seus alunos, parabéns!
Eduardo Dorneles
Aprendi React na plataforma da DevMedia há cerca de 1 ano e meio... Hoje estou há 1 ano empregado trabalhando 100% com React!
Adauto Junior
Já fiz alguns cursos na área e nenhum é tão bom quanto o de vocês. Estou aprendendo muito, muito obrigado por existirem. Estão de parabéns... Espero um dia conseguir um emprego na área.