============ Предыдущие посты по теме ============

TDD (Test-driven Development) применительно к embedded системам: похоже, я догнал, как это должно быть устроено.
http://www.caxapa.ru/echo/arm.html?id=63285
http://electronix.ru/forum/index.php?showtopic=18859

Развитие идей по упрощенной отладке.
http://www.caxapa.ru/echo/arm.html?id=63474
http://electronix.ru/forum/index.php?s=&showtopic=18859

Мультиплексированный отладочный канал
http://www.caxapa.ru/echo/arm.html?id=65805

============ COG, пЫтон ============
http://www.nedbatchelder.com/code/cog/index_ru.html
http://www.onembedding.com/articles/cog-n-make/
http://www.onembedding.com/articles/cog-n-make/examples.htm

"Питон для Си-программистов"
http://www.caxapa.ru/mcu/wwwboard.html?id=57403
http://www.caxapa.ru/mcu/wwwboard.html?id=57960

============ Идея ============

Отдельный файл(ы) - module_under_test() - тестируемый модуль

Пишется "протопрограмма":

include;
декларация переменных
// COG код: Variables_List
// COG код: Variables_Input
// список всех переменных, которые видны "снаружи" в процессе тестирования
// COG генерит код, который обращается к внешнему каналу
// и по нему получает значения для тех переменных, которые надо задать перед тестовым прогоном
module_under_test();
// COG код: Variables_Out
// список всех переменных, которые надо выдать "наружу" после тестирования
// COG генерит код, который обращается к внешнему каналу
// и по нему выдает значения переменных

Test suite на пЫтоне, который все это разгребает и принимает решение о прохождении или провале теста.

Далее "протопрограмма" компилится COG в сишную программу. Сборка, прошивка, тестировние, запуск - стандартными средствами.

Основной кайф состоит в том, что не надо руками выписывать код, который общается с отладочным каналом. Там все однотипно, можно сделать шаблон, и вперед! Но в отличие от универсальных тествых либ все будет работать при ограниченном объеме памяти.
http://cunit.sourceforge.net/index.html
http://check.sourceforge.net/

Все будет очень экономично по памяти по ресурсам, так что удастся впихнуть в целевой контроллер и целевую задачу, и отладочный код.

Т.е. даже для примитивных контроллеров можно устроить полностью автоматическое тестирование без участия человека.

РУЛЕЗ!!!

Во все не влезет наверно, у меня в мегу48 целевой код впихивается пинком асма.
Инетесно, в живую бы посмотреть на эту технологию. А почему именно питон?

Сообщение отредактировал klen - Aug 21 2006, 12:23

Ну значит придется для тестирования одну ATmega88 пожертвовать Вот додумаю - начну делать. пЫтон - правильный он. Очень.

А чем он правельней Ticl/Tk, я за него голосовать буду, этот друг уж точно везде портирован.

пЫтон тоже на все портирован - все оси, смартфоны, и пр.

Насчет сравненеия с Tcl - не готов квалифицированно ответить. Пока я чувствую, что пЫтон правильнее, и все тут.