Desenvolvimento de máquinas de estado com desenvolvimento orientado a testes

Como os modelos de máquina de estado são amplamente usados ​​em sistemas embarcados, este artigo explora várias estratégias para desenvolver software de máquina de estado (SM) sob a abordagem Test-Driven Development (TDD). Esta publicação começa explicando os conceitos básicos da máquina de estado e a técnica TDD. Finalmente, ele apresenta métodos simples e ordenados para desenvolver software de máquina de estado escrito em C usando a abordagem TDD.

Um modelo SM é composto de estados, transições e ações. Enquanto um estado é uma condição de um sistema ou elemento, uma transição é um caminho de um estado para outro, geralmente iniciado por um evento de interesse que conecta um estado predecessor (origem) com um estado subsequente (destino). Os comportamentos reais executados pelo elemento são representados em ações.

Na máquina de estado UML, as ações podem ser associadas à entrada em um estado, saída de um estado, uma transição per se, ou o que é chamado de "transição interna" ou "reação". Todos os formalismos da máquina de estado (incluindo máquinas de estado UML) assumem universalmente que uma máquina de estado completa o processamento de cada evento antes de começar a processar o próximo. Este modelo de execução é denominado Run To Completion (RTC). Neste modelo, as ações podem levar algum tempo, mas quaisquer eventos pendentes devem esperar até que a máquina de estado seja concluída - incluindo toda a ação de saída, a ação de transição e a sequência de ações de entrada nessa ordem.

Antes de tratar das estratégias de desenvolvimento de máquinas de estado utilizando TDD, vale mencionar sua definição, importância e aplicação.

Em primeiro lugar, TDD é uma técnica para construir software de forma incremental. Simplificando, nenhum código de produção é escrito sem primeiro escrever um teste de unidade com falha. Os testes são pequenos. Os testes são automatizados. O test-drive é lógico, ou seja, em vez de mergulhar no código de produção (deixando o teste para depois), o praticante de TDD expressa o comportamento desejado do código em um teste. Uma vez que o teste falha, o praticante de TDD escreve o código, fazendo com que o teste seja aprovado. No centro do processo TDD, há um ciclo de repetição composto de etapas curtas conhecidas como “microciclos TDD”.

As etapas do ciclo TDD na lista a seguir são baseadas no livro de James Grenning ‘Test-Driven Development for Embedded C’:

• Adicione um pequeno teste.
• Execute todos os testes e se o novo falhar, pode nem mesmo ser compilado.
• Faça as pequenas alterações necessárias para passar no teste.
• Execute todos os testes e comprove se o novo foi aprovado.
• Refatore para remover duplicações e melhorar a expressividade.

Vamos usar o diagrama da Figura 1 para encontrar uma maneira mais simples de desenvolver uma máquina de estado usando TDD. Quando a máquina de estado é inicializada, ela começa no Estado A Estado. Assim que receber o Alpha evento, a máquina de estado faz a transição para o EstadoB estado executando as ações xStateA (), effect () e nStateB () nessa ordem. Então, como se pode testar o SM da Figura 1 para determinar se ele se comporta de maneira adequada?

Figura 1. Máquina de estado básico (Fonte:VortexMakes)

A forma mais tradicional e simples de testar um SM como a Figura 1 consiste principalmente em verificar a tabela de transição de estados do SMUT (State Machine Under Test). Isso torna um caso de teste por estado , em que o SMUT é estimulado pelos eventos de interesse para verificar quais transições são acionadas. Ao mesmo tempo, isso implicará na verificação do estado de destino e das ações executadas para cada transição disparada. Se uma ação for suficientemente complexa, é mais adequado fazer um caso de teste específico para isso. (O artigo Testando máquinas de estado usando teste de unidade explica essa estratégia em detalhes).

Cada caso de teste é dividido em quatro fases distintas de acordo com os padrões xUnit:

• Configuração estabelece as pré-condições do teste, como o estado atual do SM ( Estado A ), o evento a ser processado ( Alfa ), e os resultados de teste esperados, que são o estado de destino de transição ( EstadoB ) e a lista classificada de ações a serem executadas (xStateA (), effect () e nStateB ()).
• Exercício estimula a máquina de estado com o Alpha evento.
• Verificar verifica os resultados obtidos.
• Limpeza retorna a máquina de estado em teste ao seu estado inicial após o teste. É opcional.

A estratégia mencionada acima é suficiente para desenvolver um SM usando TDD. No entanto, em alguns casos, mais de uma única transição é necessária para verificar a funcionalidade. Isso porque o efeito só fica visível devido a uma cadeia de ações de transições subsequentes, o que significa que a funcionalidade envolve um conjunto de estados, eventos e transições do SMUT. Nesses casos, é mais apropriado testar um cenário completo e funcional do que transições de estado isoladas. Como resultado, os casos de teste são mais funcionais e menos abstratos do que as estratégias mencionadas anteriormente.

Vamos usar a máquina de estado da Figura 2 para explorar esse conceito.

Figura 2. A máquina de estado DoWhile (Fonte:VortexMakes)

A Figura 2 mostra uma máquina de estado chamada DoWhile, que modela um loop de execução semelhante a um "do-while". DoWhile foi desenhado usando a ferramenta Yakindu Statechart. As ações ‘x =0’ e ‘output =0’ são chamadas quando DoWhile é criado e essas ações definem o valor padrão de todos os atributos DoWhile. O número de iterações de loop deve ser definido por meio de ‘x ++’ ou ‘x =(x> 0)? x–:ações x ’. A ação ‘i =0’ estabelece as condições iniciais para o loop. O corpo do loop é executado pela ação ‘i ++’, que mantém as iterações do loop, então a condição de terminação é avaliada pelo pseudoestado de escolha através do guarda ‘i ==x’. Se for verdade, o corpo do loop é avaliado novamente e assim por diante. Quando a condição de término se torna falsa, o loop termina executando a ação ‘output =i’.

É útil criar uma lista de teste antes de desenvolver uma nova funcionalidade. A lista de testes deriva da especificação e define a melhor visão do que deve ser feito. Como não precisa ser perfeita, a lista anterior é apenas um documento temporário que pode ser modificado posteriormente. A lista de teste inicial para DoWhile é mostrada abaixo:

• Todos os dados são definidos por padrão após a inicialização do SM
• Atributo de incremento X
• Decremento do atributo X
• Um único loop de iteração pode ser executado
• Um loop de iteração múltipla pode ser executado
• Um loop de não iteração pode ser executado
• Verifique os valores fora dos limites

A fim de desenvolver a máquina de estado DoWhile, Ceedling e Unity serão usados ​​junto com a técnica de programação mais simples, mas lúcida:o uso de sentenças de ‘switch-case’. Ceedling é um sistema de construção para gerar um ambiente completo de teste e construção para um projeto C; O Unity é um equipamento de teste leve e expressivo em linguagem C para projetos em C.

Dois arquivos representam essa máquina de estado, DoWhile.h e DoWhile.c, portanto, são o código-fonte em teste. A Listagem de código 1 mostra um fragmento do arquivo test_DoWhile.c, que implementa a lista de teste acima aplicando a estratégia mencionada anteriormente. Para manter este artigo simples, a Listagem de código 1 mostra apenas o caso de teste:‘Um único loop de iteração pode ser executado’, que é implementado por test_SingleIteration (). O código e o modelo estão disponíveis no repositório https://github.com/leanfrancucci/sm-tdd.git.

Listagem de código 1:teste de iteração única (Fonte:VortexMakes)

Este teste verifica se DoWhile pode executar apenas uma iteração corretamente. Para fazer isso, o test_SingleIteration () inicializa a máquina de estado DoWhile chamando DoWhile_init () (linha 96). Ele define o número da iteração para zero a ser executado pelo loop DoWhile. Depois disso, o DoWhile está pronto para processar eventos chamando DoWhile_dispatch (). Para executar uma única iteração, test_SingleIteration () envia o Up evento para DoWhile (linha 97). Este evento aumenta o número da iteração para um. O teste inicia o loop enviando o Iniciar evento (linha 98), então ele envia o Alfa para que DoWhile execute uma única iteração (linha 99). Isso é verificado verificando se o valor do atributo out é igual ao número de iterações executadas (linha 101). Finalmente, DoWhile deve permanecer no EstadoC estado (linha 102).

Para provar que DoWhile pode executar mais de uma iteração, o test_SingleIteration () é estendido conforme mostrado na Listagem de código 2.

Listagem de código 2:teste de iteração múltipla (Fonte:VortexMakes)

O teste test_NoneIteration () mostrado na Listagem de código 3 verifica se DoWhile não executa nenhuma iteração ao receber um Alpha evento sem definir previamente o número da iteração por meio de Up eventos.

Listagem de código 3:teste de não iteração (Fonte:VortexMakes)

Embora os detalhes de implementação de DoWhile não sejam o objetivo deste artigo, a Listagem de código 4 e a Listagem de código 5 mostram parte dos arquivos DoWhile.c e DoWhile.h. Na verdade, esses arquivos representam uma implementação demonstrativa de DoWhile usando sentenças de ‘switch-case’ em C.

Listagem de código 4:fragmento da implementação DoWhile (Fonte:VortexMakes)

Listagem de código 5:fragmento da especificação DoWhile (Fonte:VortexMakes)

Ambas as estratégias apresentadas acima fornecem métodos simples e ordenados para desenvolver software de máquina de estado usando TDD - uma das abordagens mais importantes para aumentar a qualidade do software.

A primeira estratégia consiste principalmente em verificar a tabela de transição de estados do SMUT. Este método cria um caso de teste por estado . A outra estratégia propõe realizar um caso de teste para um cenário completo e funcional , que frequentemente envolve um conjunto de estados, eventos e ações do SMUT. Essa segunda estratégia torna o teste mais funcional e menos abstrato do que a primeira. Embora essas estratégias sejam independentes de um tipo específico de sistema, linguagem de programação ou ferramenta, elas são muito úteis em sistemas embarcados, porque muitas delas têm comportamento baseado em estado que é normalmente definido em uma ou mais máquinas de estado.

A linguagem C foi escolhida por ser uma das linguagens mais populares para o desenvolvimento de software embarcado. Assim, para aplicar o TDD nessa linguagem, foram escolhidos Ceedling e Unity. Para concluir, esses métodos definitivamente permitem que os desenvolvedores criem de uma forma mais simples e ordenada um software muito mais flexível, sustentável e reutilizável do que as abordagens tradicionais.