- PVSM.RU - https://www.pvsm.ru -
Прочитав статью «Тестирование встроенных систем» [1] и комментарии к ней я был несколько поражен тем фактом, что многиее знакомы с книгой «Test Driven Development for Embedded C (Pragmatic Programmers)» [2] и framework-ом Unity [3], но не используют весь арсенал средств, которые предлагают ребята из throwtheswitch.org [4].
Хочу кратко поделится опытом использования этих самых средств.
Так получилось, что я нарабатывал свой опыт в программировании встраиваемых систем через тесты (Unit, Integration, System, Stress). За три года мне посчастливилось пройти путь от Junior'a и написания тестов, покрывающих код других специалистов, до Senior'a с опытом разработки систем с использованием TDD методологии.
Упомянутый выше framework Unity очень прост и удобен в использовании. Но это всего лишь вершина айсберга. На странице throwtheswitch.org [4] есть следующие инструменты.
CMock — инструмент позволяющий автоматически генерировать Си-код mock-ов для Ваших тестов. Написан на Ruby. Утверждаю, как человек, который на протяжении трех лет «генерировал» mock-и руками — это просто подарок для Си-разработчика. Но использовать его автономно без следующего инструмента, на мой взгляд, не рационально.
Ceedling — это целая билд-система, как утверждают сами авторы. Но по сути — это все, что Вам нужно для работы. Данный пакет содержит в себе все необходимое: Unity («тест-раннеры» и «чекалки» значений), CMock (генератор моков) и поддержку командной строки через ruby make.
Other — под этим странным заголовком находится очень, полезный, на мой взгляд инструмент — CException. Невероятно маленькая библиотека для Си позволяющая получить некое подобие исключений. Но дезинформировать не буду. В проектах использовать не довелось.
Единственное, что оставляет желать лучшего в этом многообразии прекрасных вещей, так это tutorial. Его, как бы, и нет. Все понятно, но с чего новичку начать — большой вопрос. Попробую исправить ситуацию.
Прежде всего, Ceedling должен быть корректно установлен и проверен на работоспособность как указано тут [5].
После установки создаем папку и тестовое окружение проекта командой:
ceedling new MyNewProject
В результате будет создана папка MyNewProject внутри которой будут сгенерированы следующие папки и файлы:
Пора писать первый тест.
Поместим в папку test файл test_calc.c следующего содержания:
#include "unity.h"
#include "calc.h"
void setUp(void)
{
}
void tearDown(void)
{
}
void test_add( void )
{
int result = 0;
result = calc_add(2,2);
TEST_ASSERT_EQUAL_INT( result, 4 );
}
Запускаем тест командой:
rake test:test_calc.c
Результат ожидаемый. Тест есть, кода нет. Проект не может быть собран.
Добавляем код.
В папку src помещаем два файла:
«calc.h»
#ifndef CALC_H
#define CALC_H
int calc_add(int a, int b);
#endif
«calc.c»
#include "calc.h"
int calc_add(int a, int b)
{
return a + b;
}
Повторяем сборку и попытку прогнать тест:
rake test:test_calc.c
Если все сделано правильно, то в консоли должны быть результаты теста:
Test 'test_calc.c'
------------------
Compiling test_calc_runner.c...
Compiling test_calc.c...
Compiling calc.c...
Compiling unity.c...
Compiling cmock.c...
Linking test_calc.out...
Running test_calc.out...
-------------------------
OVERALL UNIT TEST SUMMARY
-------------------------
TESTED: 1
PASSED: 1
FAILED: 0
IGNORED: 0
Этот короткий пример показывает, что test-runner был сгенерирован и добавлен в сборку автоматически. Его код можно найти в папке build/test/runners.
Попробуем усложнить задачу и предположим, что наш «боевой» файл должен уметь считать только при определенном условии, проверка которого осуществляется в другом программном модуле (например, rules.c). Модифицируем код, для иллюстрации:
«calc.c»
#include "calc.h"
#include "rules.h"
int calc_add(int a, int b)
{
if (rules_is_addition_allowed())
{
return a + b;
}
return 0;
}
Добавим еще один файл в папку src:
«rules.h»
#ifndef RULES_H
#define RULES_H
int rules_is_addition_allowed(void);
#endif
Попытка запустить тест будет неудачной, так как нет определения для функции rules_is_addition_allowed().
Самое время воспользоваться CMock.
Изменим тест следующим образом:
#include "unity.h"
#include "calc.h"
#include "mock_rules.h"
void setUp(void)
{
}
void tearDown(void)
{
}
void test_add( void )
{
int result = 0;
rules_is_addition_allowed_ExpectAndReturn(1);
result = calc_add(2,2);
TEST_ASSERT_EQUAL_INT( result, 4 );
}
void test_add_off_nominal( void )
{
int result = 0;
rules_is_addition_allowed_ExpectAndReturn(0);
result = calc_add(2,2);
TEST_ASSERT_EQUAL_INT( result, 0 );
}
Таким образом, мы получили автоматически сгенерированный mock одним лишь указанием "#include «mock_rules.h». Исходный код данного файла можно найти в директории build/test/mocks. Его изучение даст хорошее представление о том, каким образом можно менять поведение подменяемого модуля.
1. Я использую данный framework только для тестирования кода на PC. Это диктует определенные правила к архитектуре разрабатываемого ПО. Прогонять юнит тесты на реальном железе смысла не вижу. HAL — он либо работает либо нет и тестируется мануально (мое видение ситуации);
2. Я не использую данный framework для тестирования нескольких потоков. Потокобезопастность данного инструмента мной не исследовалась;
3. Данная статья не учит как правильно писать код и/или тесты, а всего-лишь дает краткое представление об упомянутых выше инструментах разработки.
Автор: 0xFE
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/tdd/76114
Ссылки в тексте:
[1] «Тестирование встроенных систем»: http://habrahabr.ru/post/239387
[2] «Test Driven Development for Embedded C (Pragmatic Programmers)»: http://www.amazon.com/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X/ref=sr_1_2
[3] Unity: http://throwtheswitch.org/white-papers/unity-intro.html
[4] throwtheswitch.org: http://throwtheswitch.org
[5] тут: http://throwtheswitch.org/white-papers/ceedling-intro.html
[6] Источник: http://habrahabr.ru/post/244835/
Нажмите здесь для печати.