Юнит тесты для "системного" приложения
Тогда получается, что мы о них не знаем.
-----
Ну так Я об этом уже не первый день говорю.
Да, можно написать в соответствии с документацией. И оно даже будет работать.
Но только в каких-то идеальных условиях.
В реальной среде - работать не будет - получаемое отличается от описанного.
способ доставки данных никак не связан с самими данными.
-----
Способ - нет. А вот что будет получено - уже, увы, да...
неполное описание
-----
Для отдельного изолированного устройства - вполне достаточное. 
А так - да, не полное, не описывает многое из того что имеет место быть.
Сеть - это уже способ доставки данных
-----
В данном случае - весьма сильно отличающаяся от привычных tcp/ip сетей.
У меня складывается впечатление что мы обсуждаем разные
вещи.
-----
Угу...
Я всего лишь говорю, что чтобы сделать работающий код надо знать с чем работаешь.
Ну а мне пытаются объяснить что достаточно сделать по документации.
В большинстве случаев написанное по документации - достаточно, но вот в этом случае - нет - надо ковырять реальную сеть чтобы понять возникающие проблемы. Мало того, в данной сети есть проблемы, для понимания которых недостаточно уметь грамотно работать с тцп/ип сетями, хотя, обычно, прикладная программа работает именно с ип&портом... ну или с усб-портом...
У "черного ящика" есть только вход и выход.
-----
Угу...
Вот только не вполне определено что именно понимается под "черным ящиком".
Документация, которая доступна, описывает функционирование отдельного устройства.
Соответственно код написанный по данной документации будет корректно работать с устройством.
Можно тестировать - все пройдет нормально.
Вот только де-факто "черным ящиком" является не устройство, а сеть.
Документации на сеть - нет. Все что есть - устройств может быть много, они могут быть разаными и взаимодействовать.
А поведение устройства в сети весьма отличается от того что описано в документации.
В реальной среде - работать не будет - получаемое отличается от описанного.
Ну так это задача никак не совместима с юнит тестами. В лучшем случае это integration test. И то это чисто для проверки, что мы не сломали то, о чём знаем.
Вот написал я юнит тест для использования функции перемещения файлов. Никакого доступа к диску, никах файлов. Отлично обрабатывает все исключения и прочее.
Но, в реальной среде не работает...иногда. Например, если в каталоге (target) уже есть такой файл, он не перезаписывается, а выдается исключение. Которое обрабатывается правильно.
Почти полная аналогия с твоими устройствами.
Я всего лишь говорю, что чтобы сделать работающий код надо знать с чем работаешь.
А что кто то пытается с этим спорить?
Вот только не вполне определено что именно понимается под "черным ящиком".
Вполне себе определено:
Чёрный я́щик — термин, используемый для обозначения системы, внутреннее устройство и механизм работы которой очень сложны, неизвестны или неважны в рамках данной задачи.
Вот только де-факто "черным ящиком" является не устройство, а сеть.
Ты уж определись, что у тебя там является черным ящиком.
Документации на сеть - нет. Все что есть - устройств может быть много, они могут быть разаными и взаимодействовать.
А поведение устройства в сети весьма отличается от того что описано в документации.
Все это очень мило, но не имеет никакого отношения к юнит-тестам. Да и вообще к тестам. Любой тест, хоть юнит, хоть интергационный, хоть системный, любой, построен на том, что у тебя есть заранее известный вход и заранее известный выход. И есть некий заранее известный сценарий по которому ты гарантированно получаешь конкретную ошибку. Если нет этих 3-х составляющих (вход, выход и сценарий), то ты не можешь убедиться в том, что ошибка была исправлена.
Как видишь, в тестировании нет никаких случайных величин.
Есть правда тестеры, которые ищут ошибки... но в конечном счете из 3-х параметров им известен 1, а остальные 2 (выход и сценарий) они ищут "в слепую". Но рещультат их работы все равно 3 известных параметра - вход, вызод и сценарий. Ну
и лично я считаю, что эта работа - бесполезная трата времени, т.к. стоит дорого, а выхлоп минимальный.
задача никак не совместима с юнит тестами.
-----
Вполне совместима.
Только надо выяснить как именно мокать систему...
Например, если в каталоге
-----
Ну а об чем Я спрашивал когда увидел описание задачи?
В винде там еще и локи на файлах случаются. Причем - неожиданные...
Почти полная аналогия с твоими устройствами.
-----
Аналогия только в том, что глюки редкие. По ФС всегда можно что-то откопать, а по этой сети практически ничего не находится - редкие задачи...
А что кто то пытается с этим спорить?
-----
Ну убедить то меня пытаются в другом... 
Осталось выяснить как ничего не делая получить работающий код...
Ты не получишь работающий код. Потому что ты просто не знаешь что делать 
-Приезжайте в гости
-А адрес?
-Да не надо адрес, так приезжайте.
Но Я могу поднять понимание с 20% соответствующих документации до 97%
уже где-то с 50-60% эффективное решение
Но почему 97%? Ну откуда ты вообще берешь оценку? Откуда беруться цифры при оценке понимания черного ящика? Ты месяц гонял тесты (ру юниттесты, простое исследование). Те готорые смог придумать и организовать. Как ты оцениваешь полноту тестов?
правильно в соответствии с документацией т.е. в 20% случаев,
Нет. 100% правильно в соответствии с твоим пониманием, как твой код обрабатывает работу черного ящика. Соответственно мок 100% имитирует
твое понимание работы черного ящика. Тестируя месяцы и годы можно улучшить понимание работы самого ящика, но принцип написания мока не меняется - в любой момент времени, сразу после прочтения документации или после 20 лет непрерывных тестов мок 100 процентов имитирует ответ черного ящика в строго определенной ситуации. Определенной тобой, как программистом.
Только надо выяснить как именно мокать систему...
Что то я очень в этом сомневаюсь.
Как я понял, у тебя имелась некая система, данные которой зависят от состояния самой системы, а состояния могут меняться от многих факторов.
И тебе бы хотелось написать тесты позволяющие убедится в работоспособности всей системы.
Ну убедить то меня пытаются в другом...
Мне кажется что нет. Только то, что ты хочешь получить от тестов то, что они тебе дать не могут.
есть заранее известный вход
-----
Никак не хочешь понять что нет заранее известного входа... полностью известного, по крайней мере.
А того что известно - недостаточно для написания того что нужно...
эта работа - бесполезная трата времени
-----
Но и ее тоже надо делать...
Как ты оцениваешь
-----
Если Я каким-то образом получу больше информации об функциомнировании устройства/системы чем есть в документации, то процентик - повысится. Или будет наоборот?
Тебя смущают конкретные цифирьки - ну обоснуй их неправильность...
ответ черного ящика в строго определенной ситуации
-----
Проблема в том, что в конкретном случае у тебя скорее не черный, а серый ящик.
Т.е. у тебя на одно внешнее воздействие имеется более чем один ответ.
И при этом ни один из полученных ответов может не соответствовать описанному в документации.
Понять - можно. Но не програмно. Нужно физически цеплять аппаратный порт к железу и смотреть что там происходит. - тогда станет более-менее понятно чего надо ожидать в качестве ответа устроства/системы...
Если Я каким-то образом получу больше информации об функциомнировании устройства/системы чем есть в документации, то процентик - повысится.
Вопрос стоял о целесообразности мероприятия. Например берем устройство и изучаем. И доклад - повысили информированность о системе до 97% - это одно. Доклад - а процентик то повысился Или наоборот? - это другое. Особенно если изучали месяц и к концу изучения забыли, что изучали
ебя смущают конкретные цифирьки - ну обоснуй их неправильность...
Основой для получения циферок является критерии оценки конечного результата. И в первую очередь критерии целесообразности мероприятия. Хочу все знать - это не критерий. Цифры могут быть там, где критерии оценки в цифрах. Я стал умнее информированиее на 30% - это лохотрон по определению. Просто нет критериев для оценки.
Т.е. у тебя на одно внешнее воздействие имеется более чем один ответ.И при этом ни один из полученных ответов может не соответствовать описанному в документации.
Выглядит как божественный процесс создания женщины. У Бога тоже не было документации, надо было сделать обязательно, непонятно что, задумка была прекрасная. Ну и получилось то, что получилось - "на одно внешнее воздействие имеется более чем один ответ.И при этом ни один из полученных ответов может не соответствовать"
Но и ее тоже надо делать...
Если какую-то деятельность можно описать как "бесполезная трата времени", то такую работу делать не надо... Ну если только тебе людей нечем занять и чтобы они не сидели без дела, тогда можно убить их время эмитируя полезную нагрузку :)
