Bom galera no post anterior citei alguns passos de como configurar o Rake e o Cucumber, caso não tenha lido ainda o link está abaixo:

Nessa parte final, vou mostrar a facilidade de utilizar essas maravilhas ferramentas. Nesse post vou citar e apresentar outros cenários que irão contextualizar melhor a minha motivação de escrever esse post.

No exemplo anterior tínhamos apenas uma feature cadastro com apenas 3 cenários, nesse contexto até faria sentido criar alguma task para executar esses cenários. Mas só faria sentido pra mim se o comando para rodar essa feature fosse muito grande como por exemplo a do calabash:

ADB_DEVICE_ARG= id_do_device bundle exec calabash-android run caminho_para_o_apk features/ -t @critic

Olhando pra esse comando ainda não faria sentido, você poderia usar alguma busca recursiva e achar isso no histórico do seu terminal.

Vamos criar mais uma complexidade só para mostrar a eficiência do rake com cucumber

Vamos criar mais duas features:
Primeira:

touch busca.feature

os cenários da busca.feature se encontram aqui, com isso já temos mais cenários
que precisam ser executados de forma diferente, porém ainda podemos criar mais complexidade

Segunda:

touch pull_request.feature

Cenários da pull_request.feature

Nessas features existem algumas tags

@critic = Cenários de maior valor de negócio
@slow = Cenários que demoram muito a execução
@medium = Cenários com um tempo razoável de execução
@fast = Cenários que possuem uma execução muito rápida

Como faríamos para executar essas features? Lembrando que ainda temos 3 tags de bônus 😛
@pull_request
@search
@register

Se fossemos executar apenas as features que são da feature @register teríamos o seguinte comando usando apenas o cucumber sem integração com appium, capybara e outros frameworks.

cucumber -t ~@pull_request -t ~@search

Isso vai fazer somente a feature @register seguir a execução o resto vai desaparecer do “radar” do cucumber.

Porém e se agora, alguém pedisse para rodar somente as features com tags @search e @register e utilizando somente as tags @fast e @slow?

cucumber -t ~@register -t ~@search -t ~@medium -t ~@critic

Conforme a complexidade aumenta, seu comando para criar uma execução também. Isso é
péssimo em nível de manutenção seja dos scripts do CI ou se você não tem uma boa documentação de para que servem suas tags, alguém com menor conhecimento pode ter alguma dificuldade de fazer essa abstração.

No post anterior criamos um arquivo Rake, porém ainda se encontra vazio. Vamos criar nossa primeira task e ver como a nível de complexidade fica muito fácil entender o que está acontecendo.

Agora para rodar essas tasks nós simplesmente executaríamos:

bundle exec rake fast_scenarios

Ainda assim temos que escrever muito para executar, que tal falar para suas
tasks que o bundle exec também faz parte dela?

Agora para executar essa task só é preciso utilizar o comando:

rake fast_scenarios

Até ai beleza temos um cenários legais mapeados, mas e quando começar a ter 20 tags, vamos precisar replicar todos essas tasks? NÃO.

Tasks rake também recebem parâmetros ou seja, você consegue passar qual feature e quais tags de cenário você deseja executar, então podemos mudar as tasks para:

Podemos também já incluir que em toda execução o Cucumber vai gerar relatório de cada uma dessas tags:

Para rodar esse tipo de task utilizando parâmetros ficaria dessa forma:

rake run_features['register', 'fast']

Bom é isso galera, espero que consigam abstrair tudo que eu falei por aqui e aplicar em algum projeto
que vocês tenham, não precisam se apegar apenas nesses exemplos que deixei, para o mundo mobile vocês podem
ter tasks que irão fazer o build dos projetos para vocês. A ideia é viajar na hora de criar as suas tasks 😛

Repositório do projeto

--

--

Wellington Avelino
assert(QA)

Software Eng, Testing, Build Tools, Crossfit, Cycling