Страниц: 1 ... 3 4 [5]
  Печать  
Автор Тема: Работа через USB с FlirOne Gen 2  (Прочитано 4740 раз)
lastcross
Full Member
***
Offline Offline

Сообщений: 224


Просмотр профиля
« Ответ #60 : Октября 18, 2017, 02:11:36 pm »

Цитировать
Ну, inttype.h уже давно в Си компиляторах типа Keil и IAR лежат. Нет только с плавающей точкой и bool.
Речь о том, что теперь не нужно беспокоится будет ли поддерживать конкретный компилятор или нет эти типы. Достаточно знать что компилятор полностью поддерживает с++11 чтобы не беспокоится о том, что где-то нужно что-то подключить, задефайнить или изменить в коде. Т.е. наличие этих типы - гарантированы стандартом языка.
А так, разумеется у каждого компилятора/библиотеки были возможности использовать типы с конкретным размером байт.

Цитировать
Когда работа идёт с оборудованием, этот протокол чем-то напоминает внутрипрограммный обмен - вы же почти никогда ("почти" - потому что есть случаи, когда передаёте - например, Win32API такое практикует именно по причине разных версий Windows и одних и тех же программ) не передаёте в функцию версию передаваемой структуры/объекта и её размер?

До тех пор пока вы планируете использовать это оборудование только совместно со своими программами и игнорировать версионность (развитие программ и оборудования) - до тех пор вы будете правы. Но как только возникнет необходимость использовать старую программу с новым оборудованием или новый софт который должен работать с двумя версиями аппаратуры. Или вы начнете распространять отдельно аппарат и отдельно прогу, предоставляя другим разработчикам на любом удобном языке работать с аппаратурой (считайте вы публикуете свой API к аппарату) - все станет не таким уж и радужным. В упомянутом вами WinAPI размеры передаются/передавались отчасти потому, что этим обеспечивается и версионность, валидация и совместимость с другими языками.

Цитировать
Кстати, спрошу ещё кое-что. Что бывают unit-тесты я давным-давно знаю. Но вот как их делать - без понятия.
Вам вряд-ли понадобятся unit-тесты. Подозреваю что этот подход идет в разрез с вашими представлениями о разработке (если вас не беспокоит версионность протокола, и возможность проверки пост и пред -условий).
Да, они увеличивают время разработки. Как правило требуют наличие несколько разработчиков в команде (над одним проектом).
Они нужны скорее не для выявления ошибок в работе программы. Они для выявления ошибок проектирования. Например, когда программа разрабатывается итерационно, покомпонентно. И с самого начала, с первой итерации, можно описать такие тесты которые бы проверяли корректность основных принципов при проектировании. И по мере добавления/расширения/модификации/исправления модулей эти тесты будут проверять насколько новые модули соответствуют этим тестам(принципам).
И тут даже не вопрос с сокетами/мютексами. Без них есть что тестировать в сложных проектах.
Пример автомобиль:
Запуск системы зажигания не должен приводить к движению автомобиля. Вот это "требование" по сути и является юнит-тестом. Его проверяют каждый раз например когда модифицируется любой из под-модулей системы зажигания. Изменили что-то в системе зажигания, запускаем юнит-тесты, среди которых и проверка на движение про запуск. Проверяем общий результат - даем оценку о том удачное изменение или нет. Unit-тест не отменяет дальнейшее тестирование и не гарантирует отсутствие всех ошибок (все перекрыть не возможно ими)
Цитировать
1) Unit-тест - это отдельная программа или они встраиваются в основное приложение (что странно, на мой взгляд)?

Цитировать
2) Если это отдельная программа, то делают на каждый тест одну программу или всё тестирует одна программа?
Можно так, можно этак зависит от того как у вас построен процесс тестирования

Цитировать
3) Вот есть у меня класс кодирования/декодирования принятых/отправленных данных. Чтобы его протестировать, нужно написать тест, который будет размером в пять таких классов (ведь то же самое кодирование/декодирование потребуется реализовать в программе теста). И нет никакой гарантии, что в тесте не будет ошибки. Да и как, например, убедиться, что все состояния покрыты тестом? Передаваться-то может просто тьма самых различных данных.
Тесты требуют много скучного декларативного кодирования. Классов вам писать может придется и один, но как минимум на каждый метод понадобится отдельный тест-метод (это в лучшем случае). Но с другой стороны - unit-тесты они могут быть расширяемые. Например, проверить только конкретную функциональность, позже другую и т.д.
"Хуже" всего то - что unit-тест жестко привязан к проектированию, ну как хуже - если у вас неудачное проектное решение .. то готовтесь не только перепроектировать решение но и переписать тесты (старые не подойдут)

Цитировать
4) Ряд вещей вообще непонятно как проверять - например, передачу через сокеты/CAN/USB - там всё завязано на функции ОС и работы с аппаратурой напрямую.
Вы можете раздробить проверку - проверять свой код (первично) и взаимодействие со сторонним (вторично). Т.е. остановится на том, что на такие входные данные ваш код формирует выходные данные для отправки API ОС. У вас есть набор заранее просчитанных входных и выходных данных. И как бы вы не меняли в дальнейшем код который трансформирует входные данные к выходным - юнит-тест всегда проверит что на эталонных код работает (а значит с большой долей вероятности можно сказать - трансформация происходит правильно).

Цитировать
5) Не получится ли тест программы сложнее и объёмнее самой программы раз в 5? По моим прикидкам, так и получится. Smiley
Как правило - кода будет больше, да. Притом значительно. Unit-тесты не имеют никакого значения если вы не планируете развивать код, не подходите к проблеме через проектирование, или же решение проблемы должно быть найдено в кратчайшие сроки (с минимальным количеством людей).
Записан
da-nie
Full Member
***
Offline Offline

Сообщений: 167



Просмотр профиля
« Ответ #61 : Октября 18, 2017, 06:55:23 pm »

Цитировать
До тех пор пока вы планируете использовать это оборудование только совместно со своими программами и игнорировать версионность (развитие программ и оборудования) - до тех пор вы будете правы.

А так оно, обычно, и происходит. Покупая оборудование даже одного производителя (я сейчас говорю о высокоточном и сложном оборудовании с ценой из многих нулей - что в массовом сегменте я не знаю), все модификации работают только со своими компонентами и поставляются как единое целое. Заменять компоненты без доработки производителем нельзя. Часто такое оборудование имеет протоколы обмена для дистанционного управления - там часто даже не заморачиваются с проверкой целостности команд/данных. Как пример, приборы фирмы Agilent (а это классные приборы с  часто удивительными возможностями) - обычный COM-порт и текстовый протокол. Если цифра будет искажена, мы об этом не узнаем. Поэтому тут нюанс в том, что есть "как оно было бы универсально" и то, "как это сделано почти всегда на самом деле с учётом не нужной избыточности".

Цитировать
Вам вряд-ли понадобятся unit-тесты. Подозреваю что этот подход идет в разрез с вашими представлениями о разработке (если вас не беспокоит версионность протокола, и возможность проверки пост и пред -условий).

Нет. Smiley У меня есть версионные протоколы в моих программах. Но не для оборудования, которое мы сами жёстко задаём, а для обмена клиент-серверных приложений между собой, где действительно часты обновления возможностей программ.

Цитировать
Проверяем общий результат - даем оценку о том удачное изменение или нет.

Вот с этим-то у меня и проблема. Например, есть последовательность действий, в которой важны внешние показания датчиков,текущие операции, время операций. Программа написана так, что эта последовательность ей самой и порождается в зависимости от ситуации (и набора ситуаций). Это напоминает, как человек из здравого смысла пытается не по шаблону решить задачу. То есть, самих ситуаций может быть сильно дофига (я их даже не уверен, что смогу все перечислить). Сейчас я не могу проверить, что все возможные случаи программа отрабатывает правильно.
В примерах этих самых тестов всегда тестируют некий примитив с элементарными действиями, но по факту на практике всегда имеется сложная логическая цепочка, которую протестировать будет очень непросто.

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

Дело в том, что после очередного рефакторинга хорошо бы выполнить проверку в автоматическом режиме, что и позволяют Unit-тесты. Smiley А том получается так, что я кардинально перестроил отношения классов и теперь не уверен, что не забыл в каком-либо классе о каком-либо нюансе.
Записан

И день и ночь в пути
Страниц: 1 ... 3 4 [5]
  Печать  
 
Перейти в: