Comments 26
В часах, например, нам важно, чтобы они показывали точное время, но нам всё равно как именно соединены в них шестерёнки и есть ли там шестерёнки вообще.
В часах, например, нам важно, чтобы они показывали точное время, но нам всё равно как именно соединены в них шестерёнки и есть ли там шестерёнки вообще.Были у отца товарища золотые часы вот примерно с таким браслетом, т.е. незамкнутым, пружинным — кому-то такая идея показалась свежей.
Товарищ одел отцовские часы и мы пошли гулять в лес. В лесу часы зацепились за отгибаемую ветку и катапультировались в неизвестном направлении. Последствия явки с повинной при утере взятых без разрешения отцовских зототых часов представляете. К счастью, нашли мы их, хотя потрудиться пришлось.
Это, собственно, к чему — иногда кажущаяся мелочь фрактально разрастается во что-то заметное.
Идея интересная, но ясности нет. Этот проект который вы пилите, ссылка на гитхаб у него есть? Или какие нибудь примеры тестов написанных с этим подходом, одного примера мне не достаточно чтобы понять как именно вы пишете эти тесты.
Предлагаю вам подумать над следующей аналогией: должен ли годовой бонус руководителя подразделения зависеть от того, как он лично хорошо умеет перекладывать бумажки, или же стоит оценивать работу всего подразделения под его руководством?
Ну то есть assertEqual( app.rows()[0].title(), title ) это проверка результата?
А как тогда выглядела бы проверка бумажки?
Ну так, компания состоит из департаментов, те из отделов, те из подразделений, те из команд, те из групп. И везде есть свои руководители. А работу делают простые работяги.
Какой ещё бумажки?
Это пришлось бы заинъектить шпиона, который бы запоминал параметры, с которыми его вызывали, а потом проверять были ли вызовы с заданными параметрами.
Т.е. почти всегда мы бы просто не догадались написать конкретно такой тест, который поймал бы баг (например при создании этот компонент так не планировали использовать).
Там много чего в зависимостях. И для каждой нужно по шпиону в случае модульных тестов.
Вам надо отправить программистов к тестировщикам, для обучения основам тестирования, чтобы не было таких перлов.
Конкретно в Ангуляре я делал так:
- Выпиливал инициализацию TestBed для каждого теста — это ускоряет тесты на порядок.
- При старте тестов мокал все сервисы, что общаются со внешним миром — это позволяет не писать моки в каждом тесте.
- Писал компонентные тесты, имея ввиду, что состояние может быть грязным.
Отдельная история — замокать все АПИ-сервисы сразу на все случаи жизни. При сложном бекенде это так себе. Мы это проходили.
У нас в проекте любые тесты без живого бекенда оказались нецелесообразны, поэтому сейчас только e2e тесты на реальном бекенде на копии продуктовой базы. Да долго, да ресурсы, но от остального пользы меньше, чем затрат на поддержание. Зато такие е2е тесты выявили сразу еще пачку сопутствующих проблем в инфраструктуре и на бекенде, сплошная польза вышла.
А что там такого прям сложного у вас на бэкенде? На мокнутом бэке так-то не обязательно реализовывать всю логику.
Правильно замокать флоу всех этих вариантов процессов и потом это поддерживать это тот еще спорт.
Так а зачем вам проходить все эти флоу на клиенте? Задача клиента показать текущее состояние и соответствующие ему контролы управления. А переходами уже должен бэк заниматься. Клиенту так-то должно быть по барабану какой там следующий шаг — его задача обновить своё состояние в соответствии с тем, что пришло от бэка. Иначе вам придётся переписывать клиентские тесты каждый раз, когда на бэке меняются правила переходов.
Суть руководителя не в том, чтобы говорить кому чего делать в каждый момент времени, а в том, чтобы правильно делегировать обязанности. У вас есть сложная (а то и специфичная для каждого пользователя) логика переходов — выносите её в отдельный модуль и тестируете.
Только моку в этом случае достаточно реализовать самую тривиальную схему переходов.
чувства прекрасного чуть хромает в сравнении с логической составляющей ума автора
Я не понял, чем фрактальные тесты отличаются от юнит-тестов без моков.
Если мы будем писать юнит-тесты на каждый слой приложения и запускать их от более низкого слоя к более высокому, то получится те же представленные фрактальные тесты. Или я что-то неправильно понял?
Идея с запуском тестов в порядке от менее зависимых к более зависимым — хорошая. А в современных тест-раннерах есть способ указать, какие наборы тестов после каких должны идти?
Фрактальное тестирование