Юнит тесты для "системного" приложения
В моём случае задача - приложение не должно вылетать при любых ошибках в источнике.Поэтому что и как выдает источник меня не волнует. Меня волнует, как я буду принимать данные с ошибками.
О! И если данные приходqт как текст, а ты конвертируешь его в обьект, то должен предусмотреть стандартные возможности - строка пустая или несуществует, строка не может быть конвертирована. И написать юниттесты для этих случаев, как реагирует твой код.
Черный ящик без документации... не тестировать, а мокать... Как?
Элементарно. Какое то представление о черном ящике все таки есть. Ну все публичные методы там присутствуют. С описанием параметров вызова и checked исключениями.
Именно это и мокаем. Мок должен уметь принимать те параметры, какие есть у реального обьекта и возвращать то, что возвращает реальный обьекt
Именно этого мы как раз и не знаем...
Ну во первых мы точно знаем тип данных того, что возвращает обьект. Точно.
Во вторых мы знаем, что делать с тем, что возвращает обьект. Точно.
Поэтому тесты это реакция, как правильно реагирует НАША система на все мыслемые комбинации того, что возвращает чужой обьект. И мок это будет то, как мы себе это представляем.
Например чужой обект возвращает стринг. Значит наш мок должен уметь возвращать и null. И пофиг, может это делать настоящий обьект или нет
Напримет чужой обект возвращает обьект класса. Значит наш мок должен уметь возвращать и
налль и недоинициализированный обьект класса. И пофиг, может это делать настоящий обьект или нет
обект возвращает стринг
-----
Как это замечательно, когда есть стринг! Буковки, циферьки, длина - так много информации с которой можно работать...
А как насчет какого-то двойчного набора слегка перемежаемого прерываниями? 
Да и со строками Я как-то обрисовывал весьма проблемный вариант - ЗигБии называется... 
Murr
А как насчет какого-то двойчного набора слегка перемежаемого прерываниями?
В меру своей фантазии. Черный ящик возвращает что то. Ты точно знаешь, что с этим делать. Иначе ты вообще не можешь его использовать. Ты ТОЧНО знаешь, какие проблемы могут возникнуть, иначе ты не подготовил СВОЙ код и что же ты собираешься тестовать? Вот мок и возвращяет то, что ты ожидаешь. Все мыслимые варианты. Немыслемые и неожиданные не нужны, ты все равно не готов в своем коде их отрабатывать.
Буковки, циферьки, длина - так много информации с которой можно работать...
Именно. Если твой код имеет 100500 вариантов реакции на различные варианты - нужно 100500 вариантов поведения мока. Да,
тесты рисовать может быть затратно по времени.
Ты ТОЧНО знаешь, какие проблемы могут возникнуть
-----
Ошибаешься.
Самая простая ситуаций - в доках написано - получешь текстовое сообщение из двух частей - длинны текста и самого текста в виде одной строки, где длинна указана в начале и отделена пробелом от остального текста.
Какие проблемы могут возникнуть?
иначе ты не подготовил СВОЙ код и что же ты собираешься тестовать?
-----
А почему Я должен его подготовить? У меня новомодное ТДД - сначал надо написать все тесты, а потом подгоняем под них код...
Вот мок и возвращяет то, что ты ожидаешь.
-----
Так Я не знаю что ожидать.
И доки не помогают т.к. не описывают ситуацию с достаточной полнотой.
Получить хоть какое-то понимание того что будет получатся, когда будет получатся, когда не будет получатся можно только серьезно протестив то с чем надо работать. И то не все сразу отловишь...
имеет 100500 вариантов реакции
-----
Мне, в большинстве случаев, хватает двух - принято и отвергнуто.
А вот какое из них будет - фиг его знает - даже написав корректный код по заданию получается что что-то работает не так как надо...
в доках написано - получешь текстовое сообщение из двух частей
Ну если хоть что то написано, то это меняет дело. Тут уже чистая комбинаторика
Текст/ не текст/ничего
Одна часть/2/больше
А то что документации недостаточно, это никак не меняет дело с одним набором данных.
Можно его тестировать и изучать сколько угодно, но нет никакой гарантии что другой набор даст где то такие же результаты.
Должны быть некие соглашения и определенные рамки изменения данных.
это никак не меняет дело с одним набором данных.
-----
Хи-хи...
В той сети которую Я упомянул до набора данных еще надо дойти.
Причем иногда - в прямом смысле слова - ногами - физически притопать туда где носимое устройство сможет дотянутся до другого, возможно так же носимого - сплошного покрытия сетью там нет - и поиметь возможность что-то получить/отправить.
Тут уже чистая комбинаторика
-----
Угу... Я сначала тоже так подумал... оказалось - зря.
Среди упомянутых нет как минимум еще двух-трех опций...
Причем таких, что даже зная что они возможны будет проблемно получить их с устроства.
На тестирование кода они мало влияют - ну не нашел и не протестил... но гробят обработку на раз... пустяки - подумаешь кто-то загнется от сердечного приступа об котором изначально было сообщение...
Должны быть некие соглашения и определенные рамки изменения данных.
------
Хи-хи... Ты хочешь другой протокол поверх или в дополнение к имеющемуся.
Увы - для этого надо поменять устройство... а после смены оно подлежит повторной сертификации... а на это никто не пойдет.
В той сети которую Я упомянул до набора данных еще надо дойти.
Доступность набора данных - это вообще совершенно другая проблема.
Причем таких, что даже зная что они возможны будет проблемно получить их с устройства.
А зачем их тогда вообще получать, если о них знать?
но гробят обработку на раз
Ну так дело в обработчике. Если правильно написано, то вне зависимости от исходных данных ничего не должно упасть.
Ты хочешь другой протокол поверх или в дополнение к имеющемуся.
Нет, только лишь нормальное описание имеющегося.
А почему Я должен его подготовить?
Потому что неважно с чего ты начинаешь, с тестов или с кода. Ты должен знать, что нужно сделать. Если не знаешь - то ничего делать не надо.
получешь текстовое сообщение из двух частей - длинны текста и самого текста в виде одной строки, где длинна указана в начале и отделена пробелом от остального текста.Какие проблемы могут возникнуть?
Ну получил ты стринг. Ок. Это просто строка. Твой следующий шаг? Что ты будешь со строкой делать?
Так Я не знаю что ожидать.
Тогда ничего не делай. Что ты собираешься программировать, если ты ВООБЩЕ ничего не знаешь? Если ты вообще не знаешь, что придет с черного ящика, ты физически не можешь с ним работать.
т.к. не описывают ситуацию с достаточной полнотой.
Ты можешь запрограммировать (речь идет о исполнении задания) только на ту глубину, насколько ты знаешь "черный ящик". Именно эту глубину ты можешь покрыть тестами, неважно до имплементации задания или посл. Неважно с моком или с реальным обьектом.
Получить хоть какое-то понимание того что будет получатся, когда будет получатся, когда не будет получатся можно только серьезно протестив то с чем надо работать.
Мок - это имитация реального обьекта насколько ты его понимаешь. Слово "серьезно" это несерьезно. Например у тебя неполное понимание работы обьекта и ты слепил мок. Ок. мок несовершенен. Ты "серьезно" гонял настоящий обьект, что бы понять. Ты можешь гарантировать, что понимание теперь 100%? Если нет, то твой мок лучше предыдущего, но принципиально то же самое - то, что он будет копией реального обьекта ты гарантировать не можешь.
Но это и не надо. Еще раз. Ты не учишисья работать с реальным обьектом - "черным ящиком" используя мок. Ты тестируешь СВОЙ код на все известные тебе варианты поведения реального "черного ящика".
Мне, в большинстве случаев, хватает двух - принято и отвергнуто.
Это варианты поведения твоего кода. Вариантов поведения мока больше. Например твой пример для составной строки. Мок прислал пустую строку - отвергнуто-тест прошел. Мок не ответил в таймаут. Мок прислал сообщение о ошибке. Мок прислал строку, где длина в буквах. Мок прислал строку без разделителя. Везде твой код должен отреагировать правильно, пусть одним вариантом реакции, но на 100500 вариантов ответа мока.
А зачем их тогда вообще получать, если о них знать?
------
Их в документации нет, но они иногда случаютя...
и докопаться до них можно только при очень дотошном исследовании...
Если правильно написано, то вне зависимости от исходных данных ничего не должно упасть.
-----
Да ну? Там сеть без квитирования и без гарантии доставки...
только лишь нормальное описание имеющегося
------
Нормальное - есть. Но оно не покрывает фактическую работу устройства.
Мало того - при тестировании единичного устройства многое просто не видно.
Если не знаешь - то ничего делать не надо.
-----
Осталось выяснить как ничего не делая получить работающий код...
Твой следующий шаг?
-----
По документации - вырежу данные и буду с ними работать.
По факту - будет существенно сложнее. Причем настолько, что сразу не понять ни какие проблемы, ни откуда они, ни как с ними разбираться.
Выяснить что-то можно только поработав плотненько с сетью устройств.
Что ты будешь со строкой делать?
-----
Вот это Я у тебя хотел узнать.
ты физически не можешь с ним работать
------
А код надо сдавать и он должен быть рабочим.
только на ту глубину, насколько ты знаешь "черный ящик"
------
Т.е. ровно на столько, сколько написано в документации.
Написанное по документации в практической среде работать не будет.
Ты можешь гарантировать, что понимание теперь 100%?
-----
Нет. Но Я могу поднять понимание с 20% соответствующих документации до 97% соответствующих реальной системе.
Оставшиеся 3% Я все одно не смогу получить от устройства/среды, но могу хоть как-то интерполировать полученные из опыта 77% и задавить еще 2.9%.
Это уже будет неплохой результат. Очень даже хороший по сравнению с исходным. И даже где-то приемлемый.
Где-то, но не везде.
По секрету скажу - уже где-то с 50-60% эффективное решение будет не на уровне кода, а на уровне инфраструктуры - об этом ты вообще пока не задумывался... и даже после прочтения документации эти идеи не появятся.
твой код должен отреагировать правильно
-----
Угу. Осталось выяснить сааамую простую вещь - правильно в соответствии с документацией т.е. в 20% случаев, или правильно в соответствии с реальной ситуацией т.е. 97%.
Для 97% ты пока еще не перечислил все варианты и наиболее проблемную часть пока еще даже не упоминал.
Ты можешь запрограммировать (речь идет о исполнении задания) только на ту глубину, насколько ты знаешь "черный ящик".
Нет и не может быть никакого глубинного знания "черного ящика". У "черного ящика" есть только вход и выход. Как из входа получается выход - магия.
Меня удивляет, что об этом приходится говорить.
Их в документации нет, но они иногда случаютcя
Тогда получается, что мы о них не знаем.
Там сеть без квитирования и без гарантии доставки
У меня складывается впечатление что мы обсуждаем разные вещи.
Ты - свою бывшую проблему.
Я - просто данные
Сеть - это уже способ доставки данных.
Ну и способ доставки данных никак не связан с самими данными.
Это будет интересно только при приеме конкретного пакета.
Было бы интересно "увидеть" пример правильно спроектированного класса для приема данных, который падает при неправильных данных
Нормальное - есть. Но оно не покрывает фактическую работу устройства.
Тогда это неполное описание. Другими словами ненормальное.
при тестировании единичного устройства многое просто не видно
Ну именно это я имел в виду, говоря про единичный набор данных.
И работа устройства это совсем не то, что мы рассматриваем - прием каких либо данных.