Tutorial Zephyr OS: Como Criar o Primeiro Projeto com example-application, DeviceTree e West

Testes e CI no Zephyr usando o example-application: west twister, pasta tests/ e automação

O example-application não é só um “hello world bonito”; ele já nasce preparado para teste automatizado e CI, algo que muita gente deixa para depois — e paga caro. O README do repositório cita explicitamente o uso do west twister para rodar testes. Essa é a ferramenta padrão do Zephyr para testes unitários, de integração e até hardware-in-the-loop quando configurado.

O que é o west twister (e por que ele importa)

O Twister é o test runner oficial do Zephyr. Ele:

• descobre testes automaticamente,
• builda para uma ou várias boards,
• executa (emulação/simulação ou hardware),
• coleta resultados padronizados (pass/fail/skip).

O ponto-chave: Twister testa o firmware como o Zephyr espera, respeitando DeviceTree, Kconfig e o build system. Não é um framework “externo” improvisado; ele é parte do ecossistema.

Estrutura da pasta tests/

No template, a pasta tests/ existe justamente para demonstrar onde e como colocar testes. A convenção do Zephyr é:

tests/
 └── <nome_do_teste>/
     ├── CMakeLists.txt
     ├── prj.conf
     ├── src/
     │   └── main.c
     └── testcase.yaml

tests/
 └── <nome_do_teste>/
     ├── CMakeLists.txt
     ├── prj.conf
     ├── src/
     │   └── main.c
     └── testcase.yaml

Cada subpasta representa um teste independente. Ele é buildado como uma aplicação de teste, não como parte do app/ principal. Isso é fundamental para isolar comportamento.

testcase.yaml: o coração do teste

O arquivo testcase.yaml descreve:

• nome do teste,
• tags,
• quais plataformas/boards ele suporta,
• se é build-only ou executável,
• dependências (ex.: gpio, i2c, uart).

Exemplo mínimo conceitual:

tests:
  meu_teste_basico:
    tags: basic
    platform_allow:
      - native_posix
      - qemu_x86

tests:
  meu_teste_basico:
    tags: basic
    platform_allow:
      - native_posix
      - qemu_x86

Isso diz ao Twister: “rode esse teste nessas plataformas”. É assim que você evita tentar rodar um teste de GPIO numa plataforma que não tem GPIO.

Exemplo de teste simples (sanidade do módulo)

Suponha que você quer testar o meu_modulo_minimo criado antes.

tests/meu_modulo_minimo/prj.conf

CONFIG_PRINTK=y
CONFIG_MEU_MODULO_MINIMO=y

CONFIG_PRINTK=y
CONFIG_MEU_MODULO_MINIMO=y

tests/meu_modulo_minimo/src/main.c

#include <zephyr/ztest.h>
#include "meu_modulo_minimo.h"

ZTEST(meu_modulo_suite, test_hello_call)
{
    /* O teste aqui é simples: chamar a função sem crash */
    meu_modulo_minimo_hello();
    zassert_true(true, "Funcao executou");
}

ZTEST_SUITE(meu_modulo_suite, NULL, NULL, NULL, NULL, NULL);

#include <zephyr/ztest.h>
#include "meu_modulo_minimo.h"

ZTEST(meu_modulo_suite, test_hello_call)
{
    /* O teste aqui é simples: chamar a função sem crash */
    meu_modulo_minimo_hello();
    zassert_true(true, "Funcao executou");
}

ZTEST_SUITE(meu_modulo_suite, NULL, NULL, NULL, NULL, NULL);

Aqui você está usando ztest, o framework de testes unitários do Zephyr. Ele é leve, integrado ao kernel e feito para firmware (sem malloc pesado, sem dependência de libc “grande”).

9.5 Rodando os testes com west twister

A partir da raiz do workspace (ou do repo do projeto):

west twister -T tests

west twister -T tests

Você pode filtrar por tag, plataforma ou teste específico. Em projetos reais, o comum é:

• rodar testes rápidos localmente (native_posix, qemu_x86),
• deixar hardware real para CI noturno ou manual.

9.6 Integração com CI (.github/)

O example-application já traz a pasta .github/, mostrando como integrar com GitHub Actions. A ideia não é “copiar e colar”, mas entender o padrão:

• checkout do repo,
• west init / west update,
• build para uma ou mais boards,
• opcionalmente rodar west twister.

Isso transforma cada push em uma validação automática do seu firmware. Em produto sério, isso evita regressões silenciosas quando alguém muda Kconfig, DTS ou CMake.

9.7 Estratégia prática para projetos pequenos (realista)

Você não precisa sair testando tudo desde o dia 1. Uma estratégia saudável é:

1. Testes de sanidade
   • build do app/ para pelo menos uma board.
2. Testes de módulos críticos
   • drivers próprios,
   • bibliotecas de controle, filtros, protocolos.
3. CI mínima
   • build automático,
   • falha se não buildar.

Mesmo isso já te coloca anos-luz à frente do “compila na minha máquina”.

Encerramento do tutorial (visão de conjunto)

Com o example-application, você aprendeu:

• a trabalhar no modelo workspace application (T2),
• a clonar e adaptar corretamente um projeto Zephyr,
• a estruturar app/, prj.conf, CMakeLists.txt,
• a usar DeviceTree overlays para hardware,
• a criar threads, filas e logs de forma idiomática,
• a separar debug de produção,
• e a preparar o terreno para testes e CI desde o início.

Esse template não é “mais um exemplo”: ele é um mapa de como projetos Zephyr reais são organizados.