Для большинства рынков это не так. Стартапов, которые предлагают действительно уникальные инновационные фичи, в которых потребителю не важно качество, очень мало. И их число снижается. Большая часть рынка — это улучшаемые сервисы, энтерпрайс или b2c. Там мало принципиально новых фич, да и скорость выхода на рынок не важна. Просто чуваки хотят свои бонусы к концу года.
Проверяли ли вы свои утверждения? Большинство опенсорсных библиотек живут без юнит-тестов. Почему? Потому что их отлично тестируют их клиенты. Кроме того, в библиотеки упаковываются те штуки, которые трудно разбиваются на отдельные компоненты — сложные алгоритмы и тому подобное.
Проектов, в которых надо выкладывать фиксы каждый час, а значит, и апдейты — очень мало, и тем более неясно, как это делать без хорошего покрытия.
Фактически, в случае интеграционных тестов, люди просто пренебрегают ошибочными сценариями, тестируя happy paths.
Относительно поддержки юнит-тестов я отдельно напишу.
Если юнит использует множество других юнитов, то мы их рефакторим и мокаем.
Если у нас клиент и сервер, мы берём тестовый payload и посылаем его клиенту или серверу с соответствующими проверками.
Юнит тесты покрывают всю логику. Нет никакой магии и высшей логики, которая больше суммы частей. Интеграционные тесты появляются тогда, когда юнит тесты написаны ненадежно. И при появлении надежного тест сьюта исчезают.
Мне и не нужно знать всех вариантов. Мне нужно знать ограниченный набор вариантов, которые использует мой код, для этого существуют тесты для зависимостей. «Реальность» реальных систем преувеличена. Я напишу об этом отдельно.
Он не знает за авторизацию, он грузит данные из redux State, в которых может быть либо возвращенные данные с сервера, либо ошибка, либо нет аутентификации.
Это, вероятно, следует из контекста. Вряд ли в одном проекте сидит и AST парсер, и CRUD операции для сущности.
В остальном вы перечислили POJOs, которые возвращаются из методов, а не тестируемые классы. Какой метод у Icon?
OrderService имеет метод order — то ниоткуда не следует. Я бы предположил, что он имеет методы CRUD для entity Order, но нет необходимости гадать.
ButtonComponent норм, но component не особо добавляет смысла, разве что в контексте фреймворка какого-то. MultiplyHelper is effectively Multiplier.
OrderValidator имеет метод validate и возвращает либо boolean, либо validationresult с ошибками. OrderBuilder имеет метод Build и возвращает Order. OrderService — непонятно что делает. Вот что я имею ввиду
написано в пользовательских терминах, в зависимости от предполагаемого пользователя. типично это: если в приложении А в одном поле записана дата заказа, то она должна отражаться в определенном поле приложения Б. Т.е. база данных или прочие особенности имплементации не фигурируют в самой истории. Как под это дело написать спеки — это обсуждаемый вопрос, иногда замораживают данные в базе и хардкодят ожидаемое значение в спецификации, иногда поднимают инстанс приложения и сравнивают с ним, например.
Если юзер сам программист и в состоянии посмотреть в базу, то в истории может фигурировать и база, впрочем.
Лишь бы тот, кто определяет юзер вэлью, не был отделен от acceptance по причине того, что у него нет прав\квалификации\ и тп
Проектов, в которых надо выкладывать фиксы каждый час, а значит, и апдейты — очень мало, и тем более неясно, как это делать без хорошего покрытия.
Фактически, в случае интеграционных тестов, люди просто пренебрегают ошибочными сценариями, тестируя happy paths.
Относительно поддержки юнит-тестов я отдельно напишу.
Если юнит использует множество других юнитов, то мы их рефакторим и мокаем.
Если у нас клиент и сервер, мы берём тестовый payload и посылаем его клиенту или серверу с соответствующими проверками.
По ссылке выше очень длинный текст. Непонятно, к чему адресоваться.
Юнит тесты покрывают всю логику. Нет никакой магии и высшей логики, которая больше суммы частей. Интеграционные тесты появляются тогда, когда юнит тесты написаны ненадежно. И при появлении надежного тест сьюта исчезают.
Это странно. Компоненты перебрасываются какими то JSON сообщениями. Какая разница, по какому протоколу. Юнит тестам должно быть все равно.
martinfowler.com/bliki/TestDouble.html
Он не знает за авторизацию, он грузит данные из redux State, в которых может быть либо возвращенные данные с сервера, либо ошибка, либо нет аутентификации.
Это, вероятно, следует из контекста. Вряд ли в одном проекте сидит и AST парсер, и CRUD операции для сущности.
В остальном вы перечислили POJOs, которые возвращаются из методов, а не тестируемые классы. Какой метод у Icon?
Это реакт компонент из одного поля. Как вы предлагаете разделять ответственность?
Не из реального. Но мог бы быть из реального. А что?
Да, это хорошая опция, если проект позволяет
OrderService имеет метод order — то ниоткуда не следует. Я бы предположил, что он имеет методы CRUD для entity Order, но нет необходимости гадать.
ButtonComponent норм, но component не особо добавляет смысла, разве что в контексте фреймворка какого-то. MultiplyHelper is effectively Multiplier.
OrderValidator имеет метод validate и возвращает либо boolean, либо validationresult с ошибками. OrderBuilder имеет метод Build и возвращает Order. OrderService — непонятно что делает. Вот что я имею ввиду
Я говорю про любые тесты
Так выше же я ответил
Если юзер сам программист и в состоянии посмотреть в базу, то в истории может фигурировать и база, впрочем.
Лишь бы тот, кто определяет юзер вэлью, не был отделен от acceptance по причине того, что у него нет прав\квалификации\ и тп