Исправление dimgel, (текущая версия) :
И вот для написания этих тестов очень просится какой-нидь язык.
Вообще сильно зависит от сложности прибора и сложности тестов, но в простейшем случае я начал бы с data-driven алгоритмов. Т.е. например если тесты - просто последовательность каких-то записей в регистры для изменения состояния устройства и чтения из регистров для проверки состояния, то DSL вырождается в две команды (ну ещё пауза в миллисекундах если прибор не мгновенно реагирует), которые проще в текстовые файлы вгонять и парсить эти текстовые файлы тривиально ручками:
# w port value -- writes value to port
# p milliseconds -- pauses test execution
# r port expectedValue -- reads value from port and compares
w 100 0xf000
p 10
w 100 0xffff
p 10
r 100 0xffff
Если же нужны условия и прочие там циклы (например разное продолжение алгоритма тестирования в зависимости от возвращённого прибором значения), то я бы забабахал внутренний DSL:
using namespace testMethods;
// ну или от класса отнаследоваться, объявляющего w(), r(), p().
void testDevice() {
w(100, 0xf000);
p(10);
w(100, 0xffff);
p(10);
r(100, 0xffff); // падает если возвращено не 0xffff
// overloaded-версия r() с одним аргументом просто возвращает прочитанное значение
if (r(100) != 0xffff) {
// ...
}
}
Хм. А неплохо вышло. Собственно, я бы его в обоих случаях забабахал бы. Делать мне больше нечего как парсеры писать, даже примитивные. А тут и проверка кода компилятором, и помощь от IDE, и бесконечные возможности расширения функционала. И никакие lua не нужны, всё на основном языке проекта (каким бы он ни был).
В обоих случаях бизон - это межконтинентальной баллистической ракетой по воробьям.
Исправление dimgel, :
И вот для написания этих тестов очень просится какой-нидь язык.
Вообще сильно зависит от сложности прибора и сложности тестов, но в простейшем случае я начал бы с data-driven алгоритмов. Т.е. например если тесты - просто последовательность каких-то записей в регистры для изменения состояния устройства и чтения из регистров для проверки состояния, то DSL вырождается в две команды (ну ещё пауза в миллисекундах если прибор не мгновенно реагирует), которые проще в текстовые файлы вгонять и парсить эти текстовые файлы тривиально ручками:
# w port value -- writes value to port
# p milliseconds -- pauses test execution
# r port expectedValue -- reads value from port and compares
w 100 0xf000
p 10
w 100 0xffff
p 10
r 100 0xffff
Если же нужны условия и прочие там циклы (например разное продолжение алгоритма тестирования в зависимости от возвращённого прибором значения), то я бы забабахал внутренний DSL:
using namespace testMethods;
// ну или от класса отнаследоваться, объявляющего w(), r(), p().
void testDevice() {
w(100, 0xf000);
p(10);
w(100, 0xffff);
p(10);
r(100, 0xffff); // падает если возвращено не 0xffff
// overloaded-версия r() с одним аргументом просто возвращает прочитанное значение
if (r(100) != 0xffff) {
// ...
}
}
Хм. А неплохо вышло. Собственно, я бы его в обоих случаях забабахал бы. Делать мне больше нечего как парсеры писать, даже примитивные. А тут и проверка кода компилятором, и помощь от IDE, и бесконечные возможности расширения функционала.
В обоих случаях бизон - это межконтинентальной баллистической ракетой по воробьям.
Исходная версия dimgel, :
И вот для написания этих тестов очень просится какой-нидь язык.
Вообще сильно зависит от сложности прибора и сложности тестов, но в простейшем случае я начал бы с data-driven алгоритмов. Т.е. например если тесты - просто последовательность каких-то записей в регистры для изменения состояния устройства и чтения из регистров для проверки состояния, то DSL вырождается в две команды (ну ещё пауза в миллисекундах если прибор не мгновенно реагирует), которые проще в текстовые файлы вгонять и парсить эти текстовые файлы тривиально ручками:
# w port value -- writes value to port
# p milliseconds -- pauses test execution
# r port expectedValue -- reads value from port and compares
w 100 0xf000
p 10
w 100 0xffff
p 10
r 100 0xffff
Если же нужны условия и прочие там циклы (например разное продолжение алгоритма тестирования в зависимости от возвращённого прибором значения), то я бы забабахал внутренний DSL:
using namespace testMethods;
// ну или от класса отнаследоваться, объявляющего w(), r(), p().
void testDevice() {
w(100, 0xf000);
p(10);
w(100, 0xffff);
p(10);
r(100, 0xffff); // падает если возвращено не 0xffff
// overloaded-версия r() с одним аргументом просто возвращает прочитанное значение
if (r(100) != 0xffff) {
// ...
}
}
Хм. Собственно, я бы его в обоих случаях забабахал бы. Делать мне больше нечего как парсеры писать, даже примитивные. А тут и проверка кода компилятором, и помощь от IDE, и бесконечные возможности расширения функционала.
В обоих случаях бизон - это межконтинентальной баллистической ракетой по воробьям.