Синтаксис Rest assured для того, кто будет поддерживать тесты был более понятен. WebTestClient подробно не смотрел. Спасибо за информацию. Посмотрю подробнее.
Здраствуйте, чтобы ответить на Ваш вопрос надо сделать небольшой рефрен в сторону того, как осуществляется сетевой обмен и что такое сетевая устойчивость, ориентированная на обработку статусов http. Шаблоны поддержки сетевой устойчивости предполагают, что Вы установили соединение по url и с отвечающий стороны есть компонент, который орбрабатывает Ваши соединения. Если компоненты (nginx/tomcat/...), обрабатывающей Ваши запросы нет, то Вам и отвечать некому. Это можно воспроизвести с помощью вызова через любой доступный инструмент curl/postman/insonmnia/... по произвольному адресу, произвольного запроса. Если же Вы находитесь в экзотической ситуации, и соединение то есть, то его просто нет (исчез/удален/перемещен), но при этом Вы уверены в том, что он там должен быть/появится, то попробуйте обработать свой вызов через ->
...
try
{вызов ресурса}
catch
(отлов ошибки)
{логика повторных вызовов}
...
Чего-то более интеллектуального по тому контексту, что Вы написали и предложить/подсказать не могу )
Вам нужны критерии классификации. Этой статьёй я не брал себе задачу определить и вынести критерии выделения каждого типа анализа в отдельную сферу деятельности. Для этого мне нужно было продублировать и адаптировать информацию из приложенных ссылок. Это, наверное, другая, более теоретическая статья.
Я взял себе задачей показать, для каких задач и в каком контексте следует применить каждый из них. Дать рекомендации, сделать короткие заключения о том, что и когда использовать.
Конечно. Абзац "Типы анализа ...", по каждому типу анализа дана ссылочка на best practice. Если требуется, то могу дать ссылки на конкретные программы )
Спасибо за вопрос. Хочу обратить внимание, что данная типология не мое умозаключение. Это устоявшаяся классификация типов анализа. У каждого из них есть комьюнити, учебные программы, специальности, на которых учат на курсах и в Высших учебных заведениях. Типология есть и она определяется объектом воздействия, точкой приложения анализа. Перефразировать = заниматься графоманией. Есть специальности, есть штатные единицы в компании на которых берут системных аналитиков ( есть стандарт на данный вид деятельности, который выражен типом анализа ), бизнес аналитиков, процессных аналитиков и аналитиков данных. Можно открыть hh/ хабр карьера и по точному соответствию специальности найти конкретные вакансии.
По поводу спирали, этапов работ - понял, мысль по поводу цикличности и востребованности всех типов анализа в зависимости от развитости конкретного организационного контекста я, значит не раскрыл на столько, чтобы она была очевидна. Предполагаю, что не хватило именно иллюстрации спиральности. Добавлю.
Спасибо за вопрос. Хочу обратить внимание, что данная типология не мое умозаключение. Это устоявшаяся классификация типов анализа. У каждого из них есть комьюнити, учебные программы, специальности, на которых учат на курсах и в Высших учебных заведениях. Типология есть и она определяется объектом воздействия, точкой приложения анализа. Перефразировать = заниматься графоманией. Есть специальности, есть штатные единицы в компании на которых берут системных аналитиков ( есть стандарт на данный вид деятельности, который выражен типом анализа ), бизнес аналитиков, процессных аналитиков и аналитиков данных. Можно открыть hh/ хабр карьера и по точному соответствию специальности найти конкретные вакансии.
По поводу спирали, этапов работ - понял, мысль по поводу цикличности и востребованности всех типов анализа в зависимости от развитости конкретного организационного контекста я, значит не раскрыл на столько, чтобы она была очевидна. Предполагаю, что не хватило именно иллюстрации спиральности. Добавлю.
"Прочитал, так и не понял, почему процессный анализ вынесли в отдельный вид, ведь явно он часть системного/бизнес анализов."
Процессный анализ, это именно отдельный вид анализа со своими методами и инструментами. У него свой best practise, который направлен именно на работу по созданию/упорядочиванию процессов - https://abpmp.org.ru/resource/bpm-cbok/. Бизнес анализ направлен на решение конкретной бизнес проблемы. Системный анализ на работу над системой, а процессный на выстраивание процесса. Разные домены.
Откровенно говоря, совсем не понравился график на рисунке 2
Пузырьковой диаграммой я не пользовался именно из-за ее концепции. Она предполагает равнозначное сравнение. Тут нет равнозначного. Типы анализов перекрывают друг друга и в разных ситуациях будут вопросы о том, что же конкретно выбрать. Объяснили Вы понятно. Мысль понял. Спасибо за мнение, про график областей буду иметь в виду.
Если, уж, нам нужна архитектура, то нам нужен обзор возможных предметных областей и предметных ситуаций. Нужна классификация задач: тут у нас — торговля, тут к нас — образование, тут — производство, тут — развлечение (просмотр фильмов, прослушивание музыки), а тут — творчество (создание нового)
Вы говорите, про архитектуру конкретного решения, решений. Я говорю, про архитектуру построения системы развития ИТ.
Если мы посмотрим, на интересующую Вас область, то внутри TOGAF, есть этапам/активность - бизнес архитектура. Внутри этой активности есть область бизнес анализ (BABOK). Внутри этой области есть действия по построению целевой бизнес процессов, то есть того, как должны работать - торговля/образование/производство/... Там Вы берете какой-то существующий инструмент и с его помощью наводите порядок. Инструментов много. Например такой (ссылка) - хорошо себя зарекомендовавшие схемы процессов по разным коммерческим сферам деятельности. Тут нет концептов и нет архитектуры. Тут нужно выбрать/разработать/адаптировать модель деятельности, которую нужно последовательно воплотить в коде. Вот тут, в воплощении и появляется архитектура, которая должна соответствовать параметрам, которые я предложил Выше в разделе "Почему информационный продукт должен быть именно таким?"
Для этого нужно один раз провести формализацию всех имеющихся предметных областей и предметных ситуаций и получить стоящие за ними абстракции. А потом собирать коробочную версию программного продукта из готовых компонентов для каждого конкретного пользователя. Но этим способом никто не пользуется.
Я с Вами не соглашусь. Такой деятельностью занимаются и на это есть отдельная сфера деятельности, отдельная специализация, которой уже учат в институтах (ссылка), на профильных курсах, за деньги для уже состоявшихся специалистов. Это системный менеджмент. Да, пока, он не очень распространен, но при этом уже многие компании начинают внедрять и адаптировать его под себя.
Архитектура — это представление о том, что имеются эти самые "товары", "склады", "накладные", "регистры" и отчёты (и как они взаимодействуют).
Точно. Но тут Вы про архитектуру конкретного решения, конкретного продукта. Полностью согласен.
(Запахло ChatGPT? Да-да!!)))) А как эта процедура будет устроена внутри? Просто прочитать три числа из входного файла/потока? Или получить их прямо в визуальной форме? Но можно сделать режим мастера, и действовать строго последовательно (или каким-то образом гарантировать строгую последовательность в рамках общей формы ввода). Уже довольно много вариантов взаимодействия. А если мы хотим решать не только квадратные уравнения? А если мы хотим, чтобы пользователи сами формулировали свои задачи?
ChatGPT - не панацея. Это инструмент, которым нужно уметь пользоваться, который нужно уметь настраивать. Инженер не может не понимая инструмента его использовать. Иначе инженер не может отвечать за результаты своего труда.
А как эта процедура будет устроена внутри? Просто прочитать три числа из входного файла/потока? Или получить их прямо в визуальной форме? Но можно сделать режим мастера, и действовать строго последовательно (или каким-то образом гарантировать строгую последовательность в рамках общей формы ввода). Уже довольно много вариантов взаимодействия. А если мы хотим решать не только квадратные уравнения? А если мы хотим, чтобы пользователи сами формулировали свои задачи?
Все можно. Но как проверить, что расчет верный. Как провести тестирование/верификацию/валидацию. Как дорабатывать и развивать инструмент? Для этого должен быть кто-то, кто понимает как он работает. Нужна система вокруг инструмента. И чем более широко и масштабно мы используем инструмент, тем система будет больше, сложнее. Это эволюционные витки развития любого инструмента. Примеров, чтобы было не так в социотехнических системах нет. Как только мы начинаем применять сложные решения, так сразу вокруг этих решений начинают расти подразделения, в которых количество специалистов обслуживающих их множится и множится. И вот тут вам потребуется организационная система. Предлагаемый в моей статье концепт не про систему конкретного решения, а про техническую среду, в которой можно будет системно заниматься развитием в том числе и таких решений, которые предлагаете Вы.
И ещё. Каждой архитектуре соответствует своя схема базы данных. Можно для каждого набора взаимосвязанных сущностей создавать отдельный набор табличных объектов одного и того же вида, а можно создавать один набор табличных объектов, но хранить в таблицах разнородные данные и ещё иметь дополнительные справочники метаданных.
Можно. И такие системы уже есть. Коммерчески успешные. Например - SAP, котораzреализована как раз вот так. На обслуживание такой технической системы требуется очень много профильного персонала, которые должны работать по своим правилам. Каким правилам? - Как взаимодействовать с пользователями, как вносить изменения в справочники, как развивать систему, как адаптировать систему под конкретные изменения. Все такие системы объединены в отдельный класс систем, которые развиваются по принципам шаблонного проектирования. Это отдельное направление деятельности, которое приводит к своим виткам развития в ИТ. Например к BPMS системам или Low code системам и т.д. Но внедрив такую систему, Вам все равно придется думать и решать задачи связанные с их развитием
А так... получается, что армии разработчиков в тысячах организациях по всему миру решают одни и те же задачи. Вот это и есть ошибка на самом верхнем уровне. Меняются только аббревиатуры технологий. И постоянно устаревает код. Хотя задачи всё те же. Как-то так.
Полностью согласен. На разных витках развития мы, как отрасль, решаем одни и те же вопросы, но решаем их по разному. С разными инструментами, с разным уровнем накопленных данных, разными культурными и инженерными принципами и подходами к решению задач. Для меня это и есть эволюция.
Полностью согласен с тем, что важна - ядро, мотивация, желание. Это основа. Желание доводит начатое до конца. Мне кажется этому ни один фреймворк и подход не научит. Это закладывается на уровне семьи, на уровне культуры, на уровне воспитания.
А по поводу:
Будет-ли при тренировки красивый стадион или SAFe - думаю важно, но не настолько как первое
Позвольте ответить аналогией на аналогию.
Возьмем все тот же спорт. Скажем футбол.
В странах, где развита инфраструктура. Куча красивых стадионов больше шансов, что дети пойдут и будут заниматься футболом. и будут в перспективе приносить стране множество медалей и кубков. И от этого инфраструктура будет только расти. И это станет коммерчески выгодным всем. Детям, организациям, стране.
В стране, где нет красивых стадионов и не занимаются целенаправленным развитием инфраструктуры есть шанс выиграть что-то у кого-то когда-то, но нет шанса построить систему целенаправленного развития.
Потому что у них есть возможность, но самое главное желание - вначале продумать, потом только начинать
Спасибо за мнение и опыт. У Вас в общем-то нет вопроса, но мне кажется логичным немного ответить Вам не вступая в полемику, а продемонстрировать другую сторону медали.
Мне кажется не совсем уместным сравнивать программистов одиночек и компаний. Там где есть возможность делать в одиночку не образуется компаний. Там есть конкретный труд. Когда этот "труд" перерастает во что-то большее/великое/хорошее нужна система, чтобы целенаправленно развивать этот самый "труд". Вот тут и встает дилемма о том, как организовать целенаправленное развитие. Одиночка всегда более эффективен, чем среднестатистическая единица в группе, потому что группа 40% своих затрат тратит на синхронизацию.
Но для того, чтобы было над чем думать у каждого должен быть опыт. Тут есть 2 цикла, которые заточены под работу над опытом
Цикл PDCA (ссылка) - когда мы говорим про работу над информацией Цикл Колба (ссылка)- когда мы говорим про работу над развитием навыка
Эти циклы противопоставляются друг другу, но это в корне не верно. Один дополняет другой. Вы говорите о том, что программист более эффективен за счет того, что у него есть возможность подумать. С этим я согласен. Но я делаю шаг в сторону и думаю о том, что надо программисту, чтобы он смог "эффективно" подумать. Ему нужен опыт, который научил его быть эффективным. Это как раз Цикл Колба.
С организациями все точно так же. Есть куча работы, которую нужно делать. Нужно потому, что нет возможности делать только крутые продукты. Нужно реагировать на требования государства, нужно реагировать на изменения законодательства, нужно людям зарплату считать и т.д. Как эту всю махину организовать? Вот есть такое субъективное мнение, что так можно. На практике подтверждено, что есть компании и которых так получается эффективно. Да, их немного, но они есть. Мне кажется этого достаточно, чтобы последовать их примеру и по пути постоянных и небольших изменений из чего-то хорошего сделать что-то более хорошее )
Вот тут вопрос спорный. Точка зрения понятна. Если есть более аргументированное обоснование того, какие данные проверять, то буду рад за ссылки. Дублировать в тесте полный набор данных для проверки корректности текущего состояния - правильно, но долго/трудозатратно. Этот список будет расти вместе с кодом. Проверить в юните корректность поведения при существующих данных на мой взгляд неплохо. Поинт о том, что кто-то/что-то/когда-то изменит и не проверит то, что он сделал соответствует парадигме того, что код нужно писать так, как будто его будет поддерживать психопат, но я не уверен(не созрел) к тому, чтобы соответствовать этой парадигме. Написать тест на то, что если по коду ошибка не соответствует тому, что есть в списке -> покажи поведение, да надо, это сделает тест покрытие более полным.
Не знал/не нашел про этот инструмент для JMeter. Спасибо за информацию.
Автор - спасибо тебе большое )
Целую твой лоб и желание сделать перевод. Чего-то подобного в рускоязычном сегменте интернета не так много.
Отлично. Пусть принесет Вам пользу )
Синтаксис Rest assured для того, кто будет поддерживать тесты был более понятен. WebTestClient подробно не смотрел. Спасибо за информацию. Посмотрю подробнее.
Спасибо большое. Поправлю.
Здраствуйте, чтобы ответить на Ваш вопрос надо сделать небольшой рефрен в сторону того, как осуществляется сетевой обмен и что такое сетевая устойчивость, ориентированная на обработку статусов http.
Шаблоны поддержки сетевой устойчивости предполагают, что Вы установили соединение по url и с отвечающий стороны есть компонент, который орбрабатывает Ваши соединения. Если компоненты (nginx/tomcat/...), обрабатывающей Ваши запросы нет, то Вам и отвечать некому. Это можно воспроизвести с помощью вызова через любой доступный инструмент curl/postman/insonmnia/... по произвольному адресу, произвольного запроса.
Если же Вы находитесь в экзотической ситуации, и соединение то есть, то его просто нет (исчез/удален/перемещен), но при этом Вы уверены в том, что он там должен быть/появится, то попробуйте обработать свой вызов через ->
...
try{вызов ресурса}catch(отлов ошибки){логика повторных вызовов}...Чего-то более интеллектуального по тому контексту, что Вы написали и предложить/подсказать не могу )
Крутая статья, крутая работа.
Понятно. Спасибо.
Вам нужны критерии классификации. Этой статьёй я не брал себе задачу определить и вынести критерии выделения каждого типа анализа в отдельную сферу деятельности. Для этого мне нужно было продублировать и адаптировать информацию из приложенных ссылок. Это, наверное, другая, более теоретическая статья.
Я взял себе задачей показать, для каких задач и в каком контексте следует применить каждый из них. Дать рекомендации, сделать короткие заключения о том, что и когда использовать.
Исходя из Вашей обратной связи, это получилось.
Спасибо за мнение.
Конечно. Абзац "Типы анализа ...", по каждому типу анализа дана ссылочка на best practice. Если требуется, то могу дать ссылки на конкретные программы )
Спасибо за вопрос. Хочу обратить внимание, что данная типология не мое умозаключение. Это устоявшаяся классификация типов анализа. У каждого из них есть комьюнити, учебные программы, специальности, на которых учат на курсах и в Высших учебных заведениях. Типология есть и она определяется объектом воздействия, точкой приложения анализа. Перефразировать = заниматься графоманией. Есть специальности, есть штатные единицы в компании на которых берут системных аналитиков ( есть стандарт на данный вид деятельности, который выражен типом анализа ), бизнес аналитиков, процессных аналитиков и аналитиков данных. Можно открыть hh/ хабр карьера и по точному соответствию специальности найти конкретные вакансии.
По поводу спирали, этапов работ - понял, мысль по поводу цикличности и востребованности всех типов анализа в зависимости от развитости конкретного организационного контекста я, значит не раскрыл на столько, чтобы она была очевидна. Предполагаю, что не хватило именно иллюстрации спиральности. Добавлю.
Спасибо за вопрос. Хочу обратить внимание, что данная типология не мое умозаключение. Это устоявшаяся классификация типов анализа. У каждого из них есть комьюнити, учебные программы, специальности, на которых учат на курсах и в Высших учебных заведениях. Типология есть и она определяется объектом воздействия, точкой приложения анализа. Перефразировать = заниматься графоманией. Есть специальности, есть штатные единицы в компании на которых берут системных аналитиков ( есть стандарт на данный вид деятельности, который выражен типом анализа ), бизнес аналитиков, процессных аналитиков и аналитиков данных. Можно открыть hh/ хабр карьера и по точному соответствию специальности найти конкретные вакансии.
По поводу спирали, этапов работ - понял, мысль по поводу цикличности и востребованности всех типов анализа в зависимости от развитости конкретного организационного контекста я, значит не раскрыл на столько, чтобы она была очевидна. Предполагаю, что не хватило именно иллюстрации спиральности. Добавлю.
Здраствуйте,
Процессный анализ, это именно отдельный вид анализа со своими методами и инструментами. У него свой best practise, который направлен именно на работу по созданию/упорядочиванию процессов - https://abpmp.org.ru/resource/bpm-cbok/. Бизнес анализ направлен на решение конкретной бизнес проблемы. Системный анализ на работу над системой, а процессный на выстраивание процесса. Разные домены.
Пузырьковой диаграммой я не пользовался именно из-за ее концепции. Она предполагает равнозначное сравнение. Тут нет равнозначного. Типы анализов перекрывают друг друга и в разных ситуациях будут вопросы о том, что же конкретно выбрать. Объяснили Вы понятно. Мысль понял. Спасибо за мнение, про график областей буду иметь в виду.
У меня тоже есть аналогичный опыт использования BPMN и он показывает свою оправданность, когда для него созрела целевая аудитория.
На это есть отдельный аналитический артефакт (ссылка). Может будет полезно.
Спасибо за комментарий.
Давайте попробую пояснить свою мысль.
Вы говорите, про архитектуру конкретного решения, решений. Я говорю, про архитектуру построения системы развития ИТ.
Если мы посмотрим, на интересующую Вас область, то внутри TOGAF, есть этапам/активность - бизнес архитектура. Внутри этой активности есть область бизнес анализ (BABOK). Внутри этой области есть действия по построению целевой бизнес процессов, то есть того, как должны работать - торговля/образование/производство/... Там Вы берете какой-то существующий инструмент и с его помощью наводите порядок. Инструментов много. Например такой (ссылка) - хорошо себя зарекомендовавшие схемы процессов по разным коммерческим сферам деятельности. Тут нет концептов и нет архитектуры. Тут нужно выбрать/разработать/адаптировать модель деятельности, которую нужно последовательно воплотить в коде. Вот тут, в воплощении и появляется архитектура, которая должна соответствовать параметрам, которые я предложил Выше в разделе "Почему информационный продукт должен быть именно таким?"
Я с Вами не соглашусь. Такой деятельностью занимаются и на это есть отдельная сфера деятельности, отдельная специализация, которой уже учат в институтах (ссылка), на профильных курсах, за деньги для уже состоявшихся специалистов. Это системный менеджмент. Да, пока, он не очень распространен, но при этом уже многие компании начинают внедрять и адаптировать его под себя.
Точно. Но тут Вы про архитектуру конкретного решения, конкретного продукта. Полностью согласен.
ChatGPT - не панацея. Это инструмент, которым нужно уметь пользоваться, который нужно уметь настраивать. Инженер не может не понимая инструмента его использовать. Иначе инженер не может отвечать за результаты своего труда.
Все можно. Но как проверить, что расчет верный. Как провести тестирование/верификацию/валидацию. Как дорабатывать и развивать инструмент? Для этого должен быть кто-то, кто понимает как он работает. Нужна система вокруг инструмента. И чем более широко и масштабно мы используем инструмент, тем система будет больше, сложнее. Это эволюционные витки развития любого инструмента. Примеров, чтобы было не так в социотехнических системах нет. Как только мы начинаем применять сложные решения, так сразу вокруг этих решений начинают расти подразделения, в которых количество специалистов обслуживающих их множится и множится. И вот тут вам потребуется организационная система. Предлагаемый в моей статье концепт не про систему конкретного решения, а про техническую среду, в которой можно будет системно заниматься развитием в том числе и таких решений, которые предлагаете Вы.
Можно. И такие системы уже есть. Коммерчески успешные. Например - SAP, котораzреализована как раз вот так. На обслуживание такой технической системы требуется очень много профильного персонала, которые должны работать по своим правилам. Каким правилам? - Как взаимодействовать с пользователями, как вносить изменения в справочники, как развивать систему, как адаптировать систему под конкретные изменения. Все такие системы объединены в отдельный класс систем, которые развиваются по принципам шаблонного проектирования. Это отдельное направление деятельности, которое приводит к своим виткам развития в ИТ. Например к BPMS системам или Low code системам и т.д. Но внедрив такую систему, Вам все равно придется думать и решать задачи связанные с их развитием
Полностью согласен. На разных витках развития мы, как отрасль, решаем одни и те же вопросы, но решаем их по разному. С разными инструментами, с разным уровнем накопленных данных, разными культурными и инженерными принципами и подходами к решению задач. Для меня это и есть эволюция.
Круто, что наше обсуждение было полезно нам обоим )
Спасибо. Крутая аналогия.
Полностью согласен с тем, что важна - ядро, мотивация, желание. Это основа. Желание доводит начатое до конца. Мне кажется этому ни один фреймворк и подход не научит. Это закладывается на уровне семьи, на уровне культуры, на уровне воспитания.
А по поводу:
Позвольте ответить аналогией на аналогию.
Возьмем все тот же спорт. Скажем футбол.
В странах, где развита инфраструктура. Куча красивых стадионов больше шансов, что дети пойдут и будут заниматься футболом. и будут в перспективе приносить стране множество медалей и кубков. И от этого инфраструктура будет только расти. И это станет коммерчески выгодным всем. Детям, организациям, стране.
В стране, где нет красивых стадионов и не занимаются целенаправленным развитием инфраструктуры есть шанс выиграть что-то у кого-то когда-то, но нет шанса построить систему целенаправленного развития.
Спасибо за комментарий
Точно, так и есть:
* 1,2 - С этим поможет, структурирует, упорядочит Модель Захмана. Она прямо про это;
* 4 - Это внутри TOGAF;
* 5,6 - Это 4+1;
Спасибо за мнение и опыт. У Вас в общем-то нет вопроса, но мне кажется логичным немного ответить Вам не вступая в полемику, а продемонстрировать другую сторону медали.
Мне кажется не совсем уместным сравнивать программистов одиночек и компаний. Там где есть возможность делать в одиночку не образуется компаний. Там есть конкретный труд. Когда этот "труд" перерастает во что-то большее/великое/хорошее нужна система, чтобы целенаправленно развивать этот самый "труд". Вот тут и встает дилемма о том, как организовать целенаправленное развитие. Одиночка всегда более эффективен, чем среднестатистическая единица в группе, потому что группа 40% своих затрат тратит на синхронизацию.
Но для того, чтобы было над чем думать у каждого должен быть опыт. Тут есть 2 цикла, которые заточены под работу над опытом
Цикл PDCA (ссылка) - когда мы говорим про работу над информацией
Цикл Колба (ссылка)- когда мы говорим про работу над развитием навыка
Эти циклы противопоставляются друг другу, но это в корне не верно. Один дополняет другой.
Вы говорите о том, что программист более эффективен за счет того, что у него есть возможность подумать. С этим я согласен. Но я делаю шаг в сторону и думаю о том, что надо программисту, чтобы он смог "эффективно" подумать. Ему нужен опыт, который научил его быть эффективным. Это как раз Цикл Колба.
С организациями все точно так же. Есть куча работы, которую нужно делать. Нужно потому, что нет возможности делать только крутые продукты. Нужно реагировать на требования государства, нужно реагировать на изменения законодательства, нужно людям зарплату считать и т.д.
Как эту всю махину организовать? Вот есть такое субъективное мнение, что так можно. На практике подтверждено, что есть компании и которых так получается эффективно. Да, их немного, но они есть. Мне кажется этого достаточно, чтобы последовать их примеру и по пути постоянных и небольших изменений из чего-то хорошего сделать что-то более хорошее )
Вот тут вопрос спорный. Точка зрения понятна. Если есть более аргументированное обоснование того, какие данные проверять, то буду рад за ссылки. Дублировать в тесте полный набор данных для проверки корректности текущего состояния - правильно, но долго/трудозатратно. Этот список будет расти вместе с кодом. Проверить в юните корректность поведения при существующих данных на мой взгляд неплохо. Поинт о том, что кто-то/что-то/когда-то изменит и не проверит то, что он сделал соответствует парадигме того, что код нужно писать так, как будто его будет поддерживать психопат, но я не уверен(не созрел) к тому, чтобы соответствовать этой парадигме. Написать тест на то, что если по коду ошибка не соответствует тому, что есть в списке -> покажи поведение, да надо, это сделает тест покрытие более полным.
Мысль понятна. Да, для наглядности этот тип тестов можно было бы добавить. Но не в этом тесте, чтобы не раздувать его ответственность. Спасибо.