Frederico Moreira

Já respiro novos ares profissionais e me deparei com novos conceitos, metodologias e desafios.

Em outras experiências na minha carreira não havia trabalhando tanto com testes de integração no projetos que participei. No meu contexto atual faz parte dos testes da solução da empresa, integração com operadoras de telefonia entre outros parceiros.

Portanto o uso de mocks e stubs são constantes, resolvi escrever um post sobre essa "dupla", com o intuito de entender a diferença entre eles, além de tentar esclarecer para nossa comunidade o que são e em quais situações podemos cada um.

De forma resumida concluí que Mocks são utilizados para testar interação e Stubs para esboçar estados, entendi que ambos são Fakes, mas são muito úteis em um ambiente de desenvolvimento, que se trabalha com integração com outras plataformas, parceiros, Web Services e etc.

No meu contexto atual utilizo com maior frequência os Stubs, principalmente para testar integração com operadoras de telefonia.
Para criar um novo Stub é feita uma conexão via WebService (ServiceReference) com o parceiro, afim de buscar informações WSDL sobre o funcionamento dos seus serviços. A partir dessas informações é possível simular todos os possíveis comportamentos desta integração, gerando o que chamamos de DataCases.

DataCases são possíveis comportamentos que podem ocorrer durante uma integração. Todos os possíveis comportamentos são cadastrados em um XML de configuração e a partir deste o Stub realiza os tratamentos necessários para uma simulação. Neste XML também encontramos os DataRules que são "as regras" que definem o comportamento, ou podemos dizer que contém informações necessárias para a simulação de um comportamento.
Segue abaixo um exemplo:

No exemplo acima, temos um arquivo de configuração de um Stub que simula para o retorno para todos número de celulares consultados da operadora Claro com o DDD 31, a regra contém o filtro do tipo DDD('TypeFilter-DDD-TypeFilter') e ainda indica que o retorno irá usar as informações presentes no DataCase 0('IdDataCase-0-IdDataCase').

Vendo as informações do DataCase 0 podemos ver que o Stub retornará que o número é do tipo Pós-Pago('SubscriberType-POS-SubscriberType') e ainda que o número está Ativo('Status-A-Status') para um certo cenário de teste, onde iríamos consultar se um número é válido na operadora seriam suficientes estas informações configuradas no arquivo de configuração de um Stub.

Relacionando o Mocks e Stubs na pirâmide de automação de testes de Mike Cohn, digamos que os Mocks estão no nível de unidade principalmente para times que utilizam TDD, já os Stubs estão mais próximos do nível serviços.

[1]

Espero ter conseguido clarear os conceitos e informações sobre Mocks Stubs.

Em outras palavras, segundo Robson Castilho:

"Mocks são fakes assim como os stubs, porém um mock decide se um teste passou ou falhou. Outra forma de dizer isso é que stubs são usados em testes de estado, isto é, testes orientados ao resultado. Um método é testado e espera-se que algum resultado seja “X” ou verdadeiro ou não nulo, geralmente checando o valor retornado pelo método.
Por sua vez, mocks são usados em testes de interação, isto é, testes orientados à ação. O mock verifica se o método sob teste executa uma determinada ação (e não se ele retornou algo)."

Algumas ferramentas de Mock:

Referências:
http://martinfowler.com/bliki/TestPyramid.html
http://martinfowler.com/articles/mocksArentStubs.html
http://robsoncastilho.com.br/2010/11/20/testes-de-interacao-usando-mocks/
http://stackoverflow.com/questions/3459287/whats-the-difference-between-a-mock-stub

[1] Figura retirada do slide 17 do Elias Nogueira
http://pt.slideshare.net/elias.nogueira/todas-as-abordagens-de-testes-dentro-do-gil

Futuramente publicarei um post mais técnico com exemplo de códigos relacionados a Mocks e Stubs.

Obrigado pela visita!

Agile Testers está com uma espécie de pesquisa interessante, não só a pesquisa, mas o intuito dela também. Diferente do que todos irão pensar no primeiro momento, esta pesquisa não é para eleger o melhor contribuidor, a melhor empresa e ainda o melhor site/blog. E sim mostrar para a comunidade quem é o mais lembrado(a) por todos nós, quando pensamos em contribuição e compartilhamento de informações e/ou experiência.

Acredito que ainda seja um experimento, mas que com opiniões pode transformar em uma espécie de "Prêmio Nobel" para nossa área, motivando as pessoas a compartilhar de suas experiências e com a intenção única de prover informações que ajude o crescimento de nossa comunidade.

Participe, contribua, o tempo gasto é mínimo e você pode estar ajudando muito nossa comunidade!
Não deixe para depois!







    Firmware Ágil?


Assim como no desenvolvimento de software, conseguimos aplicar apenas algumas práticas ágeis no desenvolvimento de firmware, por existir limitações citadas no último post.
  
Pensando com uma visão de um testador ágil, durante a definição das "estórias" já atuamos ajudando com perguntas, questionando, levantando o máximo de dúvidas possíveis fazendo com que o time entenda melhor o real desejo do usuário, além de servir de apoio para um melhor planejamento das atividades. Em si tratando de firmware é muito importante já ir pensando como um testador irá testar a funcionalidade em questão, pois existe durante os testes muitas vezes a manipulação de um hardware na qual o firmware é embarcado.



Por muito tempo conversando com os desenvolvedores de firmware, pensamos que não era possível fazer TDD no desenvolvimento de firmware, pois existia algumas preocupações como conseguir emular através da IDE de desenvolvimento o comportamento do firmware já embarcado.

Até que um dos desenvolvedores fez alguns testes com Unity e percebeu que o emulador usado, atendia a simulação do comportamento do firmware embarcado. O Unity é um framework de teste unitário escrito totalmente em C, é leve e possui recursos especiais para sistemas embarcados.

Voltando as atividades do testador, durante o TDD cabe a ele, ajudar o desenvolvedor a pensar nos diferentes cenários de testes para aumentar a cobertura de testes no código, no desenvolvimento de firmware o TDD fica mais "confiável" nas mãos do desenvolvedor, uma vez que muitas vezes um parâmetro passado num método por ser até uma posição de memória.

void test_ShowSomeSillyExamples(void)
{
TEST_ASSERT_NOT_EQUAL(0, -1);
TEST_ASSERT_EQUAL_INT(1, 1);
TEST_ASSERT_EQUAL_HEX16(0x1234, 0x1234);
TEST_ASSERT_EQUAL_STRING("These Are The Same", "These Are The Same");
TEST_ASSERT_BITS(0x1111, 0x5555, 0x7175);
TEST_ASSERT_INT_WITHIN(5, 100, 102);
}
Na linha do Unity temos o Cmock que é uma framework que trabalha junto com o Unity para ajudar na criação de Mocks e Stubs de interfaces para simplificar os testes.

A integração continua é possível para a compilação do firmware , mas o desafio ainda é o embarque do firmware no hardware, mas até o momento que participei do projeto já existia possíveis contornos para este desafio.

A automação encontrava-se bem evoluida com os primeiros casos de teste automatizados já sendo executados, com o auxílio de geradores de sinais e um framework desenvolvido para o apoio da automação.

Livros para apoio:


 
Este post é o último relacionado a a testes de firmware e hardware, uma vez que nesta semana iniciei minhas atividades em uma nova empresa, onde estou tendo a oportunidade de trabalhar com testes ágeis voltados para aplicações.

Pretendo escrever a partir de agora sobre meu dia a dia atuando em times ágeis, assim como ferramentas de BDD e automação, além das novas experiências com Agile Testing.

Créditos: Felipe Provenzano