Código C do teste de unidade [fechado]

Eu trabalhei em um sistema embarcado neste verão, escrito em C. direto. Era um projeto existente que a empresa em que eu trabalhava havia assumido. Acostumei-me bastante a escrever testes de unidade em Java usando JUnit, mas não consegui a melhor maneira de escrever testes de unidade para o código existente (que precisava de refatoração), bem como o novo código adicionado ao sistema.

Existem projetos por aí que tornam o teste de unidade de código C simples tão fácil quanto o teste de código Java com JUnit? Qualquer insight que se aplicasse especificamente ao desenvolvimento incorporado (compilação cruzada à plataforma arm-linux) seria muito apreciado.

Uma estrutura de teste de unidade em C é Check ; uma lista de estruturas de teste de unidade em C pode ser encontrada aqui e é reproduzida abaixo. Dependendo de quantas funções de biblioteca padrão o seu tempo de execução possui, você pode ou não conseguir usar uma delas.

AceUnit

O AceUnit (Advanced C e Embedded Unit) se apresenta como uma estrutura de teste de unidade de código C confortável. Ele tenta imitar o JUnit 4.xe inclui recursos de reflexão. O AceUnit pode ser usado em ambientes de restrição de recursos, por exemplo, desenvolvimento de software incorporado e, principalmente, funciona bem em ambientes onde você não pode incluir um único arquivo de cabeçalho padrão e não pode invocar uma única função C padrão das bibliotecas ANSI / ISO C. Também possui uma porta Windows. Ele não usa garfos para interceptar sinais, embora os autores tenham manifestado interesse em adicionar esse recurso. Veja a página inicial do AceUnit .

Autônomo GNU

Muito parecido com o Check, incluindo bifurcação para executar testes de unidade em um espaço de endereço separado (na verdade, o autor original do Check pegou emprestada a idéia do GNU Autounit). O GNU Autounit usa o GLib extensivamente, o que significa que a vinculação precisa de opções especiais, mas isso pode não ser um grande problema para você, especialmente se você já estiver usando o GTK ou o GLib. Veja a página inicial do GNU Autounit .

cUnit

Também usa GLib, mas não bifurca-se para proteger o espaço de endereço dos testes de unidade.

CUnit

Padrão C, com planos para uma implementação da GUI do Win32. Atualmente, não bifurca ou protege o espaço de endereço dos testes de unidade. No início do desenvolvimento. Veja a página inicial do CUnit .

CuTest

Uma estrutura simples com apenas um arquivo .c e um arquivo .h que você solta na sua árvore de origem. Veja a página inicial do CuTest .

CppUnit

A principal estrutura de teste de unidade para C ++; você também pode usá-lo para testar o código C. É estável, desenvolvido ativamente e possui uma interface GUI. Os principais motivos para não usar o CppUnit for C são primeiro grandes e, depois, você precisa escrever seus testes em C ++, o que significa que você precisa de um compilador C ++. Se isso não parece uma preocupação, vale a pena considerar, juntamente com outras estruturas de teste de unidade C ++. Veja a página inicial do CppUnit .

embUnit

embUnit (Unidade incorporada) é outra estrutura de teste de unidade para sistemas embarcados. Este parece ser substituído pelo AceUnit. Página inicial da Unidade Incorporada .

MinUnit

Um conjunto mínimo de macros e pronto! O objetivo é mostrar como é fácil testar seu código de unidade. Veja a página inicial do MinUnit .

Unidade para Mr. Ando

Uma implementação CUnit que é relativamente nova e aparentemente ainda está em desenvolvimento inicial. Veja a página inicial do CUnit para Mr. Ando .

Esta lista foi atualizada pela última vez em março de 2008.

Mais estruturas:

CMocka

CMocka é uma estrutura de teste para C com suporte a objetos simulados. É fácil de usar e configurar.

Veja a página inicial do CMocka .

Critério

O Critério é uma estrutura de teste de unidade C de plataforma cruzada, que oferece suporte ao registro automático de testes, testes parametrizados, teorias e que pode gerar vários formatos, incluindo TAP e JUnit XML. Cada teste é executado em seu próprio processo, para que sinais e falhas possam ser relatados ou testados, se necessário.

Consulte a página inicial do critério para obter mais informações.

HWUT

O HWUT é uma ferramenta geral de teste de unidade com grande suporte a C. Ele pode ajudar a criar Makefiles, gerar casos de teste maciços codificados em 'tabelas de iteração' mínimas, caminhar pelas máquinas de estado, gerar stubs C e muito mais. A abordagem geral é única: os veredictos são baseados em 'stdout bom / stdout ruim'. A função de comparação, no entanto, é flexível. Assim, qualquer tipo de script pode ser usado para verificação. Pode ser aplicado a qualquer idioma que possa produzir saída padrão.

Veja a página inicial do HWUT .

CGreen

Uma estrutura de teste e zombaria moderna, portátil e em vários idiomas para C e C ++. Ele oferece uma notação opcional de BDD, uma biblioteca de simulação, a capacidade de executá-lo em um único processo (para facilitar a depuração). Um corredor de teste que descobre automaticamente as funções de teste está disponível. Mas você pode criar seus próprios programaticamente.

Todos esses recursos (e mais) são explicados no manual do CGreen .

A Wikipedia fornece uma lista detalhada das estruturas de teste de unidade C em Lista de estruturas de teste de unidade: C

Pessoalmente, gosto da estrutura de teste do Google .

A real dificuldade em testar o código C está quebrando as dependências dos módulos externos, para que você possa isolar o código em unidades. Isso pode ser especialmente problemático quando você está tentando fazer testes com o código legado. Nesse caso, geralmente me vejo usando o vinculador para usar as funções de stubs nos testes.

É a isso que as pessoas se referem quando falam sobre " costuras ". Em C, sua única opção é realmente usar o pré-processador ou o vinculador para zombar de suas dependências.

Uma suíte de teste típica em um dos meus projetos em C pode ser assim:

#include "myimplementationfile.c"
#include <gtest/gtest.h>

// Mock out external dependency on mylogger.o
void Logger_log(...){}

TEST(FactorialTest, Zero) {
    EXPECT_EQ(1, Factorial(0));
}

Observe que você está realmente incluindo o arquivo C e não o arquivo de cabeçalho . Isso oferece a vantagem do acesso a todos os membros de dados estáticos. Aqui, zombei do meu criador de logs (que pode estar no logger.o e fornece uma implementação vazia. Isso significa que o arquivo de teste é compilado e vinculado independentemente do restante da base de código e executado isoladamente.

Quanto à compilação cruzada do código, para que isso funcione, você precisa de boas instalações no destino. Eu fiz isso com o googletest cross compilado no Linux em uma arquitetura PowerPC. Isso faz sentido, porque você tem um shell completo e um SO para reunir seus resultados. Para ambientes menos ricos (que eu classifico como qualquer coisa sem um sistema operacional completo), você deve apenas criar e executar no host. Você deve fazer isso de qualquer maneira para poder executar os testes automaticamente como parte da compilação.

Acho que testar o código C ++ é geralmente muito mais fácil, devido ao fato de o código OO geralmente ser muito menos acoplado do que o procedimento (é claro que isso depende muito do estilo de codificação). Também em C ++, você pode usar truques como injeção de dependência e substituição de método para inserir costuras no código que, de outra forma, seria encapsulado.

Michael Feathers tem um excelente livro sobre o teste de código legado . Em um capítulo, ele aborda técnicas para lidar com código não-OO, que eu recomendo.

Edit : Eu escrevi uma postagem no blog sobre o código processual de teste de unidade, com a fonte disponível no GitHub .

Edit : Há um novo livro que sai dos Pragmatic Programmers que aborda especificamente o código C de teste de unidade que eu recomendo .

Minunit é uma estrutura de teste de unidade incrivelmente simples. Estou usando-o para testar o código do microcontrolador c de unidade para avr.

Atualmente, estou usando a estrutura de teste de unidade CuTest:

http://cutest.sourceforge.net/

É ideal para sistemas embarcados, pois é muito leve e simples. Não tive problemas em fazê-lo funcionar na plataforma de destino e na área de trabalho. Além de escrever os testes de unidade, tudo o que é necessário é:

• um arquivo de cabeçalho incluído onde quer que você esteja chamando as rotinas CuTest
• um único arquivo 'C' adicional a ser compilado / vinculado à imagem
• algum código simples adicionado ao main para configurar e chamar os testes de unidade - só tenho isso em uma função especial main () que é compilada se UNITTEST for definido durante a compilação.

O sistema precisa suportar uma pilha e alguma funcionalidade stdio (que nem todos os sistemas incorporados possuem). Mas o código é simples o suficiente para que você provavelmente possa trabalhar em alternativas a esses requisitos se a sua plataforma não os possuir.

Com algum uso criterioso dos blocos externos "C" {}, ele também suporta o teste de C ++.

Eu digo quase o mesmo que ratkok, mas se você tiver uma torção incorporada para os testes de unidade, então ...

Unidade - estrutura altamente recomendada para teste de código C de unidade.

Os exemplos no livro mencionados neste tópico TDD para C incorporado são escritos usando o Unity (e o CppUTest).

Você também pode querer dar uma olhada na libtap , uma estrutura de teste C que gera o TAP (Test Anything Protocol) e, assim, integra-se bem a uma variedade de ferramentas lançadas para esta tecnologia. É usado principalmente no mundo da linguagem dinâmica, mas é fácil de usar e se torna muito popular.

Um exemplo:

#include <tap.h>

int main () {
    plan(5);

    ok(3 == 3);
    is("fnord", "eek", "two different strings not that way?");
    ok(3 <= 8732, "%d <= %d", 3, 8732);
    like("fnord", "f(yes|no)r*[a-f]$");
    cmp_ok(3, ">=", 10);

    done_testing();
}

Existe uma elegante estrutura de teste de unidade para C com suporte para objetos simulados chamados cmocka . Requer apenas a biblioteca C padrão, funciona em uma variedade de plataformas de computação (incluindo incorporadas) e com diferentes compiladores.

Ele também oferece suporte a diferentes formatos de saída de mensagens, como relatórios de Subunidade, Protocolo de Teste e Protocolo XML e jUnit.

O cmocka foi criado para funcionar também em plataformas incorporadas e também oferece suporte ao Windows.

Um teste simples é assim:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
    (void) state; /* unused */
}

int main(void) {
    const struct CMUnitTest tests[] = {
        cmocka_unit_test(null_test_success),
    };
    return cmocka_run_group_tests(tests, NULL, NULL);
}

A API está totalmente documentada e vários exemplos fazem parte do código-fonte.

Para começar com o cmocka, leia o artigo em LWN.net: Teste de unidade com objetos simulados em C

O cmocka 1.0 foi lançado em fevereiro de 2015.

Não fui muito longe testando um aplicativo C herdado antes de começar a procurar uma maneira de simular funções. Eu precisava muito de zombaria para isolar o arquivo C que quero testar dos outros. Eu tentei cmock e acho que vou adotá-lo.

O Cmock verifica os arquivos de cabeçalho e gera funções simuladas com base nos protótipos encontrados. O Mocks permitirá que você teste um arquivo C em perfeito isolamento. Tudo o que você precisa fazer é vincular seu arquivo de teste com zombarias, em vez dos arquivos de objetos reais.

Outra vantagem do cmock é que ele validará os parâmetros passados ​​para as funções simuladas e permitirá especificar o valor de retorno que as simulações devem fornecer. Isso é muito útil para testar diferentes fluxos de execução em suas funções.

Os testes consistem nas funções testA (), testB () típicas nas quais você cria expectativas, chama funções para testar e verificar afirmações.

O último passo é gerar um corredor para seus testes com unidade. Cmock está vinculado à estrutura de teste da unidade. A unidade é tão fácil de aprender quanto qualquer outra estrutura de teste de unidade.

Vale a pena tentar e muito fácil de entender:

http://sourceforge.net/apps/trac/cmock/wiki

Atualização 1

Outro quadro que estou investigando é o Cmockery.

http://code.google.com/p/cmockery/

É uma estrutura C pura que suporta testes de unidade e zombaria. Não depende de ruby ​​(ao contrário do Cmock) e tem muito pouca dependência de bibliotecas externas.

Requer um trabalho um pouco mais manual para configurar simulações, porque não gera geração de código. Isso não representa muito trabalho para um projeto existente, já que os protótipos não mudam muito: depois de ter suas simulações, você não precisará alterá-las por um tempo (este é o meu caso). Digitação extra fornece controle completo de zombarias. Se há algo que você não gosta, você simplesmente muda sua zombaria.

Não há necessidade de um corredor de teste especial. Você só precisa criar uma matriz de testes e passá-la para uma função run_tests. Um pouco mais de trabalho manual aqui também, mas definitivamente gosto da idéia de uma estrutura autônoma independente.

Além disso, contém alguns truques bacanas de C que eu não conhecia.

A Cmockery geral precisa de um pouco mais de compreensão das zombarias para começar. Exemplos devem ajudá-lo a superar isso. Parece que ele pode fazer o trabalho com uma mecânica mais simples.

Como novato em C, achei os slides chamados Desenvolvimento orientado a testes em C muito úteis. Basicamente, ele usa o padrão assert()junto &&para entregar uma mensagem, sem nenhuma dependência externa. Se alguém estiver acostumado a uma estrutura de teste de pilha cheia, isso provavelmente não funcionará :)

Nós escrevemos FRAUDE (hospedado no GitHub ) para fácil usabilidade e portabilidade.

Não possui dependências e não requer instalação ou configuração. Apenas um arquivo de cabeçalho e um caso de teste são necessários.

#include <cheat.h>

CHEAT_TEST(mathematics_still_work,
    cheat_assert(2 + 2 == 4);
    cheat_assert_not(2 + 2 == 5);
)

Os testes são compilados em um executável que cuida da execução dos testes e relata seus resultados.

$ gcc -I . tests.c
$ ./a.out
..
---
2 successful of 2 run
SUCCESS

Tem cores bonitas também.

Existe CUnit

E Embedded Unit é uma estrutura de teste de unidade para o Embedded C System. Seu design foi copiado de JUnit e CUnit e mais, e depois adaptado para o Embedded C System. A Unidade Incorporada não requer bibliotecas C std. Todos os objetos são alocados para a área const.

E Tessy automatiza o teste de unidade de software incorporado.

Eu não uso uma estrutura, apenas uso as ferramentas automáticas "verificam" o suporte ao destino. Implemente um "main" e use assert (s).

Meu diretório de teste Makefile.am se parece com:

check_PROGRAMS = test_oe_amqp

test_oe_amqp_SOURCES = test_oe_amqp.c
test_oe_amqp_LDADD = -L$(top_builddir)/components/common -loecommon
test_oe_amqp_CFLAGS = -I$(top_srcdir)/components/common -static

TESTS = test_oe_amqp

O livro de Michael Feather, "Trabalhando efetivamente com o código legado", apresenta muitas técnicas específicas para testes de unidade durante o desenvolvimento em C.

Existem técnicas relacionadas à injeção de dependência específicas de C que eu não vi em nenhum outro lugar.

CppUTest - Estrutura altamente recomendada para código C de teste de unidade.

Os exemplos no livro mencionados neste tópico TDD para C incorporado são escritos usando CppUTest.

Eu uso o CxxTest para um ambiente c / c ++ incorporado (principalmente C ++).

Eu prefiro o CxxTest porque ele possui um script perl / python para criar o executor de teste. Depois de uma pequena inclinação para configurá-la (menor ainda porque você não precisa escrever o executor de teste), é muito fácil de usar (inclui amostras e documentação útil). O maior trabalho foi a configuração do 'hardware' que o código acessa para que eu pudesse testar efetivamente a unidade / módulo. Depois disso, é fácil adicionar novos casos de teste de unidade.

Como mencionado anteriormente, é uma estrutura de teste de unidade C / C ++. Então você precisará de um compilador C ++.

Guia do usuário do CxxTest Wiki do CxxTest

diferente do meu viés óbvio

http://code.google.com/p/seatest/

é uma maneira simples e agradável de testar o código C da unidade. imita o xUnit

Depois de ler o Minunit, pensei que uma maneira melhor era basear o teste em macro assert, que eu uso muito como técnica de programa defensivo. Então, usei a mesma idéia de Minunit misturada com afirmação padrão. Você pode ver minha estrutura (um bom nome poderia ser NoMinunit) no blog do k0ga

cmockery em http://code.google.com/p/cmockery/

O Google possui uma excelente estrutura de testes. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

E sim, até onde eu sei, funcionará com C simples, ou seja, não requer recursos C ++ (pode exigir compilador C ++, não tenho certeza).

Cmockery é um projeto lançado recentemente que consiste em uma biblioteca C muito simples de usar para escrever testes de unidade.

Primeiro, veja aqui: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

Minha empresa possui uma biblioteca C que nossos clientes usam. Usamos o CxxTest (uma biblioteca de teste de unidade C ++) para testar o código. O CppUnit também funcionará. Se você estiver preso em C, recomendo o RCUNIT (mas o CUnit também é bom).

Se você está familiarizado com o JUnit, recomendo o CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Isso pressupõe que você tenha um compilador c ++ para fazer os testes de unidade. caso contrário, tenho que concordar com Adam Rosenfield que verificar é o que você deseja.

Usei o RCUNIT para fazer alguns testes de unidade para código incorporado no PC antes de testar no alvo. Uma boa abstração da interface de hardware é importante; caso contrário, os registros de mapeamento de memória e memória vão matá-lo.

tente lcut! - http://code.google.com/p/lcut

Verificador de integridade da API - estrutura de teste para bibliotecas C / C ++:

Um gerador automático de testes de unidade básicos para uma biblioteca C / C ++ compartilhada. É capaz de gerar dados de entrada razoáveis ​​(na maioria, mas infelizmente não em todos) casos para parâmetros e compor casos de teste simples ("qualidade sanitária" ou "qualidade rasa") para cada função na API através da análise de declarações no cabeçalho arquivos.

A qualidade dos testes gerados permite verificar a ausência de erros críticos em casos de uso simples. A ferramenta é capaz de criar e executar testes gerados e detectar falhas (segfaults), interrupções, todos os tipos de sinais emitidos, código de retorno diferente de zero e interrupção do programa.

Exemplos:

• Conjunto de testes para fontconfig 2.8.0
• Conjunto de testes para o FreeType 2.4.8

Uma técnica a ser usada é desenvolver o código de teste de unidade com uma estrutura C ++ xUnit (e compilador C ++), mantendo a fonte do sistema de destino como módulos C.

Certifique-se de compilar regularmente sua fonte C em seu compilador cruzado, automaticamente com seus testes de unidade, se possível.

O LibU ( http://koanlogic.com/libu ) possui um módulo de teste de unidade que permite dependências explícitas de suítes / casos, isolamento de testes, execução paralela e um formatador de relatórios personalizável (os formatos padrão são xml e txt).

A biblioteca é licenciada por BSD e contém muitos outros módulos úteis - rede, depuração, estruturas de dados comumente usadas, configuração etc. - caso você precise deles em seus projetos ...

Estou surpreso que ninguém tenha mencionado o Cutter (http://cutter.sourceforge.net/). Você pode testar C e C ++, ele se integra perfeitamente às ferramentas automáticas e tem um tutorial muito bom disponível.

Caso você esteja direcionando as plataformas Win32 ou o modo de kernel do NT, dê uma olhada no cfix .

Se você ainda está procurando estruturas de teste, o CUnitWin32 é um para a plataforma Win32 / NT.

Isso resolve um problema fundamental que eu enfrentei com outras estruturas de teste. Ou seja, variáveis ​​globais / estáticas estão em um estado determinístico porque cada teste é executado como um processo separado.