Готовлю я тут потихоньку платфому для новых проектов, и возникла вот
такая задача.

Есть код на C. Plain ANSI C, все чин-чинарем. Система функций, из
которых снаружи виден только вход и выход.

Часто возникает задача оттестировать этот код в режиме симуляции (т.е.
запускаем его, на вход данные от программного генератора, на выход -
интеллектуальных анализатор). Ну и так на пару суток (по крайней
мере, моя жаба будет спокойна, что мой супер-пупер компук оправдывает
свою супер-пуперность, и есть шанс уговорить ее на upgrade)

Например, есть у меня код распознавания DTMF. Его много гуляет по
инету Но для серьезного приложения мне хочется как следует все
оттестировать: подать на вход (методом монте-карло, например) разные
наборы данных (шум, абсолютная амплитуда несущих, разность амплитуд,
различных длительности паузы и пр.) и посмотреть, что получится.

Тестировщик довольно прост: задаем данные, генерируем отсчеты, и на
вход. Он пишет лог: в какой последовательности мы чего на вход
подавали.

"Приниматель" данных просто пишет лог - в какой последовательности
чего приняли.

Ну и анализатор этих логов - где чего взглюкнуло.

Лично я (может, я старомоден?) после такой проверки спал бы куда
спокойнее, чем даже после такого замечательного моделирования, как тут
http://aly.projektas.lt/Projects/MATLAB/DT...coderEvanse.htm

Собственно, тут нет никакого противоречия - MATLAB совершенно
замечательная вещь для разработки, я же говорю о полностью
автоматизированное методике тестирования.

Возникает вопрос, как это сделать? Если использовать нормальную
embedded OS (типа eCos) в режиме синтетического порта (когда OS и
подчиненные ей задачи живут под Linux), то понятно. Устраиваем связь
наших функций с тестером посредством Linux IPC (Inter Proces
Commnunication) и тестируем до посинения.

Но возникает вопрос, на чем писать сам тестер?

С не очень катит, т.к. быстродействие "тестера" не так важно (IMHO), а
вот простота его разработки и ошибкоустойчивость куда важнее. IMHO,
Python (или другой высокоуровневый скриптовый ООП язык - например,
RUBY тоже хорош) подойдет куда лучше.

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

Нашлась вот такая штука
http://www.swig.org/

SWIG is a software development tool that connects programs written in
C and C++ with a variety of high-level programming languages. SWIG is
used with different types of languages including common scripting
languages such as Perl, PHP, Python, Tcl, Ruby and PHP. The list of
supported languages also includes non-scripting languages such as C#,
Common Lisp (CLISP, Allegro CL, UFFI), Java, Modula-3 and OCAML. Also
several interpreted and compiled Scheme implementations (Guile,
MzScheme, Chicken) are supported. SWIG is most commonly used to create
high-level interpreted or compiled programming environments, user
interfaces, and as a tool for testing and prototyping C/C++ software.
SWIG can also export its parse tree in the form of XML and Lisp
s-expressions. SWIG may be freely used, distributed, and modified for
commercial and non-commercial use.

http://codeguru.com/csharp/.net/net_asp/sc...cle.php/c11103/
статья по теме

Я пока толком не разобрался, но по доке выглядит просто супер!

Вопросы:

1. Кто-нибудь этот SWIG юзал? Как оно?
2. Какие вообще существуют продвинутые методики проверки С программ?

не знаю как си...
а вот для си плас плас - тут немного не с того уровня нужно заходить. не с инструментария, а с идеологии. Точнее с методологии. И в процессе производства софта это должно начинаться НЕ за программистом, а ПЕРЕД аналитиком и сборщиком инфы от пользователя.
На мой взгляд для этих целей катит Обьектно Ориентированный подход.

удачи Вам

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

В настоящее время вся эта идеология выглядит так.

Я начинаю писать целевую задачу "сверху" на высокоуровневом скриптовом языке. Бустродействие, память меня не колышут. Все внутренний функции заменяю заглушками. Добиваюсь, чтобы модель заработала, проверяю логику работы "внутренностей".

Далее постепенно я перевожу внутренности на С, и поключаю их к этой скриптовой программе. На том же скриптовом языке пищу тестировочные модули, которые "натягивают все по полной".

Так постепенно я опускаюсь до кода, который засовываю в железо. Поскольку он на С, то эффективность будет высокой.

Параллельно с этим другой человек под оговоренную ось пишет дрова для выбранноо железа.

На этапе симуляции дрова заменяются эмулятором, протокол общения с дровами сохраняется на протяжении всего жизненного цикла системы.

Я конечно не ярый поклоник XP методологии проектирования, но тест-юниты - это гуд!.
http://www.xprogramming.ru/XPRules/UnitTests.html
http://www.xprogramming.ru/Articles/TDD-Ruby.html
http://cunit.sourceforge.net/
http://www.ozon.ru/context/detail/id/15016...buyalso_1616782

Сначал тесты, ну а пиво-девушки-заказчики потом.
Ключеове - Test-Unit.
Есть системы автоматической сборки проектов с последующей прогонкой тестов.

Да... Вот ради таких крупиц знаний и стоит "пылесосить форумы".....
Цитата с формуа xprogramming.ru:
"Если вы будете задавать вопросы по Windows XP - мы вас найдем и убьем!"

В общем, я в ауте. Как выяснилось, готовясь к новому проекту, я частично изобрел этот велосипед... И парное программирование, и тест юниты...
Ну что же, приятно, что я не одинок в своих мыслях. Будем читать, и переносить эффективную часть всей этой философии в embedded мир.

Жаль, книжку "Кент Бек. Экстремальное программирование: разработка через тестирование" уже не купить. Будем искать скан.

P.S. Ну что за гадство: почему в 2003 году была издана масса интереснейших профессиональных книг малыми тиражами 3..5 к экземпляторов, их раскупили, и пока не переиздали. Если книгу раскупили - значит, она интересна, и неплохо бы допечатать тираж. Что, читающая публика интересуется только печатным ...ством интересуюется "ххх для ламеров"?

Был на днях в Доме Книги на Арбате - был приятно поражен. Народу масса, серьезных книг тоже. Жаль, финансы пока не соотвествуют желаниям. По моим прикидкам, ~30кР стоит оставить там. Но переиздания старых книг нет.

P.P.S. Интересно, а у нас когда-нибудь свой аналог amazon заведется? Чтобы можно было в нормальной среде б/у книги покупать/продавать, чтобы там был свой хороший склад по редким и ценным книгам и пр. Или о таких прелестях в стремительно дурнеющей стране можно уже и не мечтать? Как-то грустно жить без веры в прекрасное, а менять страну проживания в 37 лет поздно и как-то не хочется...

Хотя есть и парадокс - уродства в масс-медиа просто немеренно, но приличные молодые люди попадаются: хорошо говорят, мыслят свободно и незашорено, ведут себя очень почтительно. ШпыЁны что ли?

Сорри за

Вот еще линочка (если никогда не были на rsdn):
http://www.rsdn.ru/res/book/prog/beck.xml
http://www.rsdn.ru/Forum/?mid=414288

Здорово что вы прониклись подходом XP (по частям он известен всем, и многи частями его пользуют, но бек смог сделать резюме).
Но в embedded я с трудом вместе с ним...
Типичная "проблема":
Например есть на плате устройство, управляется через SPI.
Пишу класс управления устройством. Устройство одно! Тут либо паттерн singletone что правильно, либо все методы и члены сделать как static, что быстро для исполнения и компактно по коду....
Вот и приплыл. Не могу себя отучить для embedded писать нормально.
Применение static вместо паттерна "одиночка" затрудняет тестирования, так нельзя сделать наследование интерфейса, и гонять програмно подставленые потоки. Либо приходится заранее в класс внедрять возмодность поставы, что тоже хреново.

TDD я тоже не смог купить. Брал почитать у друзей (они по XP рабоатют уже года 4).
Книг очень много хороших, но из книги нельзя прочитать больше чем уже знаешь.
Я постараюсь вязть TDD и отсканить. Проблема в том что кники издательства Питер трудно сканить, рассыпаются потом.

В принципе на форуме можно уже создавать раздел "методологии проектирования" для устройств, ПЛИС, программ, плат.

Например я словил кайф найдя в конфе линку на двух-процессный подход при проектировании на VHDL. Как нашел, так и сразу попал в "свою" колею, и освоение VHDL и написание "реального" железа сразу пошло веселее. В этом аспекте были бы интересны обзоры по проектирования тестовых заданий для HDL.

Забыл...
Чтобы начать рекомендую полистать Алана Купера (кажись так) книга называется "Психбольница", чего-то там в руках пациента. Книга серьезная. Главно прокинуть первые 40-50 страниц мути для убеждения менеджеров что деньги тратить надо.
Весьма повеселит и внесет живость в работу, особенно если приходится общаться с заказчиками и руководить командой. После прочтения проникся к ментору, интерфес для HyperLynx - практически шедевр.

Это?
http://www.bolero.ru/product-36418704.html
Психбольница в руках пациентов
Купер А.
Переплёт: мягкий
Объём: 336 стр.
ISBN: 5932860715
Дата выхода: 2004 г.
Издательство: Символ-Плюс »

Я это себе пока представляю более примитивно.

Весь I/O - в дровах через кольцевые буфера. Это зависит только от железа.

Вся обработка начинается с буферов. С код работает с входным и выходным буфером. SWIG -> подрубаем наш код к Python - и тут пишем все test units.
Еще есть такая штука
http://cunit.sourceforge.net/index.html
CUnit A Unit Testing Framework for CDone!
http://electronix.ru/forum/index.php?showtopic=12180&hl=Да, это разумная мысль!

Да, эта "Психбольница в руках пациентов"
За книги Бека спасибо.
Про буфера я немного не понял, поискал в конфе нашел обсуждение в этом же разделе "Универсальная среда".

Я стараюсь писать код так чтобы его можно было скомпилить в VS.
Все "железные" объеты должны иметь абстрактный интерфейс, чтобы на стороне ПК при написании кода не было разногласий, да внутри железки тоже это гуд.
Писать стараюсь только на C++.
Это позволяет переиспользовать оклоко 50% кода на стороне ПК при написании интерфейса (обернул все добро в COM server и опа.. можешь работаь из матлаба).
Поэтому большинство тестов я провожу на ПК, в компофртных условиях.
Синхронизация проектов для железа и ПК через репозиторий.

Ладно, дальше я так понимаю обсуждение идет уже в теме "Универсальная среда". Буду там продолжать.

Естественно, C код должны быть Plain C по максимум (ну разве что при утаптывании в железо asm вставка в обработчике прерываний появится)Строго!А вот тут загвоздка. В целевое устройство код на ++ писатькак-т стремно - не так пока ++ компилеры отшлифованы, как С (особенно для мелких контроллеров, например, AVR). Для тестирования (IMHO) Python приятнее. Задачи эффективно писать чисто виндовые приложения нет - Python + Tkinter за глаза.За это я и борюсь! Максимум, что надо делать в железа - дебужить низкоуровневый драйвер периферии. Все остальное должно быть вылизано на писюке!Да.
спасибо за идеи!