Pull to refresh

Comments 12

Я периодически думаю можно ли делать интеграционные тесты, но на не моковых ответах API.

Цель такая - быть уверенным что все не отвалится не только на "правильных" ответах API, а на тех что есть сейчас.

Юнит-тесты реактовских компонент — невероятно бессмысленная вещь. Очень недалеко от Enterprise FizzBuzz.


Означает ли, что если юнит-тесты пройдут — наши компоненты будут правильно отображаться и работать? Нет, не означает. Да и принципиально не может, потому что всё, что мы проверили — это делают ли наши компоненты в замокированном DOM некоторые вещи, которые мы ожидаем. От этого и до "компонент правильно отображается и работает" — пропасть, со дна которой на тебя смотрят страшные штуки по имени CSS, browser compatibility, и всё вот это.


Означает ли, что если юнит-тесты не пройдут — наши компоненты не будут правильно отображаться и работать? И опять же нифига: на моей практике на каждую сотню случаев отвала юнит-тестов компонентов примерно штук 5 сообщали о реальных проблемах, а остальные 95 — это "я чего-то поменял в компоненте и теперь мне надо поправить тест, чтоб не падал".


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

Не соглашусь с вами.

Интеграционный тест компонента показывает, что внутренняя логика работает как ожидается.

Если вам приходится переписывать тесты если не изменился функционал, то у вы пишете странные и бесполезные тесты.

Интеграционный тест компонента показывает, что внутренняя логика работает как ожидается.

И случаев, когда вам в компоненте нужно столько логики, что её уже неплохо бы тестировать — крайне мало. Но поскольку случаи наворачивания логики внутрь компонента обычно (обычно в идеале, а не обычно когда усилиями традиционных "программистов на реакте" в компонентах оказывается весь код проекта) касается специфических разборок с DOM, то даже и тут тестирование этого на ненастоящем игрушечном DOM — бесполезно.


Если же ваша "внутренняя логика" компонента не совершенно примитивна (взяли уже приготовленные данные, отобразили эти данные как есть) и не написана ради оптимизаций и решения сложных проблем DOM — то ей не место внутри компонента.


Если вам приходится переписывать тесты если не изменился функционал, то у вы пишете странные и бесполезные тесты.

Вы статью-то вообще читали? Когда сторона тестов дёргает сторону тестируемого кода через селекторы, завязывающиеся на конкретные теги, классы, или (обоже) тексты — вам неизбежно придётся писать "странные и бесполезные" тесты, которые будут ломаться так сразу, как только в компоненте поменяется хоть что-нибудь по его форме (и плевать, что по смыслу не поменяется ничего).

Во-первых, в контексте rtl тестирование компонентов уже не является юнит. Т.к. рендерит все потомки тестируемого компонента. Во-вторых, что плохого в покрытии веток кода тестами? В-третьих, е2 тесты все равно должны быть. То есть всегда можно выбрать другие типы тестирования не взамен, а в помощь.

Во-первых, в контексте rtl тестирование компонентов уже не является юнит.

Да, и поэтому нужно тащить что-то еще для мокирования компонент (типа enzyme), если уж вы вступили на эту кривую дорожку. А то еще и тесты будут не юнит, а хренпоймичто.


Во-вторых, что плохого в покрытии веток кода тестами?

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


В-третьих, е2 тесты все равно должны быть.

Какое отношение это всё имеет к rtl и статье? Я где-то в своем комментарии сказал, что тестов не надо вообще?

мокирования компонент (типа enzyme)

При чём тут мокирование? Если у меня, условно, импорт компонента из mui, то он совершенно обычно зарезолвится в тестовом окружении.

Ровно то же плохое, что и в лопаньи пузырьков на пленке

Неостроумные аналогии не по делу - вот что бесполезно.

Какое отношение это всё имеет к rtl и статье? 

Самое прямое. Речь о тестировании.

Когда сторона тестов дёргает сторону тестируемого кода через селекторы, завязывающиеся на конкретные теги, классы, или (обоже) тексты — вам неизбежно придётся писать "странные и бесполезные" тесты

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

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

Соглашусь в одном - логику из компонентов нужно выносить.

Если у меня, условно, импорт компонента из mui, то он совершенно обычно зарезолвится в тестовом окружении.

Это зависит исключительно от вашего тестового окружения. Может и не зарезолвиться. Почти все тестовые обвязки умеют (и обильно практикуют) вмешиваться в "обычные резолвы".


Неостроумные аналогии не по делу — вот что бесполезно.

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


Самое прямое. Речь о тестировании.

Rtl никак не относится к e2e и принципиально не может.


Пожалуй, только в русском сообществе можно встретить настолько некомпетентное, но переполненное важностью, мнение.

Это всегда очень иронично, когда мне пишут абзац голословного текста, сводящийся к "вы ничего не понимаете в N", а сразу за ним — процитированное ^_^


Большинство описанных проблем решены несколько лет назад и активно используется очень многими разработчиками, которые по вашему мнению "лопают пузырики".

Так что именно решено? Ваши компоненты всегда сверстаны с идеальнейшем соответствием семантике html? Ваши классы никогда не меняются? У вас всегда есть intl с дефолтными болванками текстов? И так в любом вашем проекте?
Если это всё надо, чтоб rtl можно было удобно пользоваться — то я, пожалуй, не буду. В моем мире такая идеальность даже не ночует обычно. А жить как-то надо.


Соглашусь в одном — логику из компонентов нужно выносить.

Что вы тогда собрались в них тестировать? Как они взяли кусок данных и обернули его в <span>? А это точно настолько нетривиально, что без тестов никуда?

Не тестируй библиотеку, тестируй свой код. Для всего скопа языков так говорят. Для мира js не так?

PS: для критичных сценариев есть более верхнеуровневые тесты, предлагаю это не обсуждать обсуждая юниты и их убойность

Не тестируй библиотеку, тестируй свой код. Для всего скопа языков так говорят. Для мира js не так?

Ну так что вы протестируете, взяв реакт-компоненты и rtl?
Море всего, на самом деле, но "своего кода" там будет совсем чуть, а проверять его поведение вы будете внутри вороха абстракций. В то время, как для презентационного слоя единственный критерий прохождения или не прохождения приемки — это чтоб оно всё появилось в реальном браузере и отработало в нем же. Работает ли оно внутри абстракций rtl — это вообще абсолютно никого не волнует.

страшные штуки по имени CSS, browser compatibility, и всё вот это.

Как эти проблемы решает описанный подход?

 остальные 95 — это "я чего-то поменял в компоненте и теперь мне надо поправить тест, чтоб не падал".

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

тестируйте бизнес-логику,

Как этому противоречат юнит тесты?

Как эти проблемы решает описанный подход?

Какой "описанный подход"?


И это только стор и роутер из явных зависимостей.

Мой "стор" выражается ключевым словом class и никаких зависимостей, не относящихся к работе с данными приложения не требует. А к чему вы тут роутер припахали — для меня вообще загадка. Роутер не относится к работе с данными.


С накрученными по пути контекстами, кастомными хуками, редукс мидлварями и прочим, о каком-то рефакторинге будут говорить разве что шепотом.

Если вы работаете с редаксом — мои соболезнования. Я не работаю и никому не советую этого делать.
Контексты и хуки относятся к реакту, и к работе над данными никогда не привлекаются. Да и не должны. Если вы без реакта не можете написать модельную часть приложения (работу с данными, собссно) — проблема в вас.


Как этому противоречат юнит тесты?

Я где-то написал, что юнит-тесты этому противоречат?

Sign up to leave a comment.