К заказчику надо ехать уже с готовым

Эти голубые мечты у меня тоже были вначале.

Но даже есть это и так, есть интернет стики и VPN

А в Китае не довелось бывать?

Пока пользовался VPN вечером из отеля какое то время работало. Как попользовался днем, все - заблокировали. Гугла там тоже нет, кстати.

Симку иностранцу купить практически нельзя, а мобильной связи из помещений довольно часто нет, заводы то не в городе.

Вторую фунцию обозреть еще проще, т.к. всего две строчки

Это смотря с какой стороны подойти. В первом случае сразу видно что СОМ порт и как пересылается и что там еще ошибка есть, а во втором случае надо это все искать.

Я не могу сказать априори какая функция лучше, все зависит от конкретной ситуации. И относительно тестирования тоже.

Если мне нужно послать в СОМ порт "А" и получить "Б", а все остальные проблемы - ошибка, то можно даже и таймаутом не заморачиваться. Не оттого что не хочется, а оттого что на это просто нет времени.

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

И если в одном варианте меня волнует, а что будет если шнур выдернут или неправильные данные придут, то во втором это просто не интересует.

у меня на ноуте COM порта вообще нет

Для это есть "сумочка" там переходник "УСБ-СОМ порт", есть еще и виртуальный СОМ порт

Если бы ты сказал, что тебе это для тестирования, то врядли кто-нибудь стал бы возражать

Могли бы и манунг кинуть - нецелевой расход рабочего времени и как следствие невыполнение задания в срок

но это все очень затратные способы

Все проблема в том чтобы понять отчего происходит ошибка у конкретного клиента.

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

Вот у нас на одном устройстве был световой барьер (луч света перекрывается или нет) для обнаружения перемещения кусков материала (довольно длинных кусков)

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

Но начали с анализа логов и выяснили что датчик светового барьера дает какие то странные сигналы, попросили проверить датчик. В итоге оказалось что заказчик просверлил технологические отверстия в материале и они "попали" прямо на датчик.

Исправилось перемещением датчика. Как это можно было покрыть тестами, я не представляю.

Так что всё очень зависит от конкретной ситуации.

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

Эх, хотелось бы что вы это на практике попробовали, с нашими устройствами и сроками.

Я могу потратить какое то время и написать эмулятор оборудования (кое где он и вправду есть) и прийти к устройству допустим через неделю, когда прога замечательно стала работать после всех тестов.

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

А потом оказывается, что данные приходят не так как предполагалось и надо алгоритм переделывать и т.п. и т.д.