Как стать автором
Обновить

Комментарии 26

Это 5, но.
В часах, например, нам важно, чтобы они показывали точное время, но нам всё равно как именно соединены в них шестерёнки и есть ли там шестерёнки вообще.

Были у отца товарища золотые часы вот примерно с таким браслетом, т.е. незамкнутым, пружинным — кому-то такая идея показалась свежей.
Товарищ одел отцовские часы и мы пошли гулять в лес. В лесу часы зацепились за отгибаемую ветку и катапультировались в неизвестном направлении. Последствия явки с повинной при утере взятых без разрешения отцовских зототых часов представляете. К счастью, нашли мы их, хотя потрудиться пришлось.
Это, собственно, к чему — иногда кажущаяся мелочь фрактально разрастается во что-то заметное.
НЛО прилетело и опубликовало эту надпись здесь

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

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

Предлагаю вам подумать над следующей аналогией: должен ли годовой бонус руководителя подразделения зависеть от того, как он лично хорошо умеет перекладывать бумажки, или же стоит оценивать работу всего подразделения под его руководством?

Аналогия интересная и вроде самоочевидная. А предлагаемое «тесты более высокого уровня полагаются на то, что тесты уровня ниже уже всё проверили» в ней же — это какой вариант?

Ну то есть assertEqual( app.rows()[0].title(), title ) это проверка результата?
А как тогда выглядела бы проверка бумажки?

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


Какой ещё бумажки?

Я так понял, что assertEqual( app.rows()[0].title(), title ) считается «проверкой работы подразделения под руководством». А как тогда выглядел бы ассерт на проверку «умения перекладывать бумажки»?

Это пришлось бы заинъектить шпиона, который бы запоминал параметры, с которыми его вызывали, а потом проверять были ли вызовы с заданными параметрами.

Шпиона вместо кого? У вас под этим компонентом что в зависимостях? Дочерние компоненты? Сервисы внутренние без выхода в сеть? Сервисы работающие с выходом в сеть для работы с АПИ? Еще что-то?
Если что — у меня не праздный интерес ко всему этому, мы сейчас на распутье — надо нам в ангуляровском проекте какие-то тесты кроме e2e или нет. И пока я глядя на фактический поток багов вижу, что остальные виды тестов для нашего проекта получаются просто нецелесообразны.

Т.е. почти всегда мы бы просто не догадались написать конкретно такой тест, который поймал бы баг (например при создании этот компонент так не планировали использовать).

Там много чего в зависимостях. И для каждой нужно по шпиону в случае модульных тестов.


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


Конкретно в Ангуляре я делал так:


  • Выпиливал инициализацию TestBed для каждого теста — это ускоряет тесты на порядок.
  • При старте тестов мокал все сервисы, что общаются со внешним миром — это позволяет не писать моки в каждом тесте.
  • Писал компонентные тесты, имея ввиду, что состояние может быть грязным.
В целом ваша идея понятна — не мокать всё подряд, мокать только сервисы работы с внешним миром. Ну хорошо если у вас такой низкий уровень связности с внешним миром, что от таких тестов много пользы.

Отдельная история — замокать все АПИ-сервисы сразу на все случаи жизни. При сложном бекенде это так себе. Мы это проходили.

У нас в проекте любые тесты без живого бекенда оказались нецелесообразны, поэтому сейчас только e2e тесты на реальном бекенде на копии продуктовой базы. Да долго, да ресурсы, но от остального пользы меньше, чем затрат на поддержание. Зато такие е2е тесты выявили сразу еще пачку сопутствующих проблем в инфраструктуре и на бекенде, сплошная польза вышла.

А что там такого прям сложного у вас на бэкенде? На мокнутом бэке так-то не обязательно реализовывать всю логику.

У нас кредитный брокер. Ключевой процесс — оформление кредитных заявок и выдача кредитов с кучей вариантов, которые приходится учитывать, т.к. мы консолидируем продукты различных банков. Одних только схем подписания 3 класса.

Правильно замокать флоу всех этих вариантов процессов и потом это поддерживать это тот еще спорт.

Так а зачем вам проходить все эти флоу на клиенте? Задача клиента показать текущее состояние и соответствующие ему контролы управления. А переходами уже должен бэк заниматься. Клиенту так-то должно быть по барабану какой там следующий шаг — его задача обновить своё состояние в соответствии с тем, что пришло от бэка. Иначе вам придётся переписывать клиентские тесты каждый раз, когда на бэке меняются правила переходов.

В теории да, но тогда и тесты все на отрисовку состояний по сути, а не на какую-то логику «руководителя» (т.е. у нас практически нет никаких ToDoList'ов хранящихся на фронте). А если мы хотим проверить реальные переходы как срабатывают — так надо тогда весь флоу реальных переходов и эмулировать.

Суть руководителя не в том, чтобы говорить кому чего делать в каждый момент времени, а в том, чтобы правильно делегировать обязанности. У вас есть сложная (а то и специфичная для каждого пользователя) логика переходов — выносите её в отдельный модуль и тестируете.

Ну так для этого и потребуется замокать весь флоу реальных переходов… или использовать реальный бекенд, что мы и делаем.

Только моку в этом случае достаточно реализовать самую тривиальную схему переходов.

Так самую тривиальную и тестировать смысла нет, ибо гораздо более сложные кейсы и так будут проверены в ходе е2е тестов, которых всё равно не избежать, т.к. проверять в сборе фронт+бекенд всё равно надо. А возможность за 5 секунд отловить ошибки до е2е тестов — так мы в этот модуль переходов изменения вносим раз в полгода максимум, поэтому нецелесообразно их проверять отдельно.
НЛО прилетело и опубликовало эту надпись здесь

чувства прекрасного чуть хромает в сравнении с логической составляющей ума автора

Я не понял, чем фрактальные тесты отличаются от юнит-тестов без моков.


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


Идея с запуском тестов в порядке от менее зависимых к более зависимым — хорошая. А в современных тест-раннерах есть способ указать, какие наборы тестов после каких должны идти?

Ага, типа того.
Я не встречал нигде.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.