Если у меня, условно, импорт компонента из mui, то он совершенно обычно зарезолвится в тестовом окружении.
Это зависит исключительно от вашего тестового окружения. Может и не зарезолвиться. Почти все тестовые обвязки умеют (и обильно практикуют) вмешиваться в "обычные резолвы".
Неостроумные аналогии не по делу — вот что бесполезно.
Аналогия совершенно прямая. Вы спросили "что плохого в покрытии веток кода тестами", я вам ответил. Само по себе "покрытие кода" — совершенно бессмысленное занятие, которое само по себе никак не увеличивает качество продукта, ни устойчивость к рефакторингу, ни еще что вы там захотите придумать. Всё, что делает "покрытие кода" — это позволяет вам вывести красивую циферку процента покрытия, которая сама по себе ни о чем не говорит, да и не может.
Самое прямое. Речь о тестировании.
Rtl никак не относится к e2e и принципиально не может.
Пожалуй, только в русском сообществе можно встретить настолько некомпетентное, но переполненное важностью, мнение.
Это всегда очень иронично, когда мне пишут абзац голословного текста, сводящийся к "вы ничего не понимаете в N", а сразу за ним — процитированное ^_^
Большинство описанных проблем решены несколько лет назад и активно используется очень многими разработчиками, которые по вашему мнению "лопают пузырики".
Так что именно решено? Ваши компоненты всегда сверстаны с идеальнейшем соответствием семантике html? Ваши классы никогда не меняются? У вас всегда есть intl с дефолтными болванками текстов? И так в любом вашем проекте?
Если это всё надо, чтоб rtl можно было удобно пользоваться — то я, пожалуй, не буду. В моем мире такая идеальность даже не ночует обычно. А жить как-то надо.
Соглашусь в одном — логику из компонентов нужно выносить.
Что вы тогда собрались в них тестировать? Как они взяли кусок данных и обернули его в <span>? А это точно настолько нетривиально, что без тестов никуда?
Мой "стор" выражается ключевым словом class и никаких зависимостей, не относящихся к работе с данными приложения не требует. А к чему вы тут роутер припахали — для меня вообще загадка. Роутер не относится к работе с данными.
С накрученными по пути контекстами, кастомными хуками, редукс мидлварями и прочим, о каком-то рефакторинге будут говорить разве что шепотом.
Если вы работаете с редаксом — мои соболезнования. Я не работаю и никому не советую этого делать.
Контексты и хуки относятся к реакту, и к работе над данными никогда не привлекаются. Да и не должны. Если вы без реакта не можете написать модельную часть приложения (работу с данными, собссно) — проблема в вас.
Как этому противоречат юнит тесты?
Я где-то написал, что юнит-тесты этому противоречат?
Не тестируй библиотеку, тестируй свой код. Для всего скопа языков так говорят. Для мира js не так?
Ну так что вы протестируете, взяв реакт-компоненты и rtl?
Море всего, на самом деле, но "своего кода" там будет совсем чуть, а проверять его поведение вы будете внутри вороха абстракций. В то время, как для презентационного слоя единственный критерий прохождения или не прохождения приемки — это чтоб оно всё появилось в реальном браузере и отработало в нем же. Работает ли оно внутри абстракций rtl — это вообще абсолютно никого не волнует.
Во-первых, в контексте rtl тестирование компонентов уже не является юнит.
Да, и поэтому нужно тащить что-то еще для мокирования компонент (типа enzyme), если уж вы вступили на эту кривую дорожку. А то еще и тесты будут не юнит, а хренпоймичто.
Во-вторых, что плохого в покрытии веток кода тестами?
Ровно то же плохое, что и в лопаньи пузырьков на пленке. То есть, в общем-то ничего, просто само по себе это совершенно бесполезное занятие, на выходе которого имеем только кучу попорченной пленки. А в нашем случае — гору кода, которая ничего полезного не делает, и будет дальше жрать время на поддержку, пока кто-нибудь её не выкинет из проекта нафиг.
В-третьих, е2 тесты все равно должны быть.
Какое отношение это всё имеет к rtl и статье? Я где-то в своем комментарии сказал, что тестов не надо вообще?
Интеграционный тест компонента показывает, что внутренняя логика работает как ожидается.
И случаев, когда вам в компоненте нужно столько логики, что её уже неплохо бы тестировать — крайне мало. Но поскольку случаи наворачивания логики внутрь компонента обычно (обычно в идеале, а не обычно когда усилиями традиционных "программистов на реакте" в компонентах оказывается весь код проекта) касается специфических разборок с DOM, то даже и тут тестирование этого на ненастоящем игрушечном DOM — бесполезно.
Если же ваша "внутренняя логика" компонента не совершенно примитивна (взяли уже приготовленные данные, отобразили эти данные как есть) и не написана ради оптимизаций и решения сложных проблем DOM — то ей не место внутри компонента.
Если вам приходится переписывать тесты если не изменился функционал, то у вы пишете странные и бесполезные тесты.
Вы статью-то вообще читали? Когда сторона тестов дёргает сторону тестируемого кода через селекторы, завязывающиеся на конкретные теги, классы, или (обоже) тексты — вам неизбежно придётся писать "странные и бесполезные" тесты, которые будут ломаться так сразу, как только в компоненте поменяется хоть что-нибудь по его форме (и плевать, что по смыслу не поменяется ничего).
А эти вообще чистые рельсы с выбором в диалогах «дать по морде» и «всё равно дать по морде». Ещё дальше от фоллаутов, чем ведьмак.
Давайте будем честными: фоллауты состоят из рельсов тоже примерно полностью (да и вообще любая CRPG), просто маскируют это чуток получше. В обоих фоллаутах один абсолютно невариабельный в ключевых событиях сюжет, два относительно разных способа пройти мейнквест в Ф1, и у каждого из этих разных способов еще по 2-3 пути, отличающихся уж совсем незначительными деталями. А в Ф2 и вовсе один способ. И дополнительные локации, почти все из которых (за исключением очень редких ситуаций) являются целиком "вещью в себе", т.е. ты можешь придти, как-то сделать или не сделать мейнквест локации, и в зависимости от исхода увидеть тот или иной финальный слайд про эту локацию, или… вообще не приходить, от этого ничего в остальном прохождении не меняется.
Разница тут в том, что биоварские РПГ тебя тычут носом в весь имеющийся у них контент (но его тем не менее тоже можно пропускать в очень больших объемах), а фоллаут не тычет. В остальном подход не меняется. И конечно фоллауты очень хорошо поддерживают иллюзию вот этого открытого мира, где много может быть иначе. Но если поковыряться в деталях — неа, не может.
Не "сложность победы", а "насколько сложно нащупать путь к победе". Это конечно любопытно, что вы второе прочитали как первое, но это совсем не одно и то же.
В игре, где вы побеждаете, если после 1000 подкидываний монетки выпадет 1000 орлов — победить невероятно сложно, а вот "нащупать путь к победе", скорее всего, довольно легко.
Да нет, вы просто смешиваете игры, где соль именно в детальности симуляции (Cataclysm: Dark days ahead как современный яркий пример), и игры, где соль в сложности победы (разными подходами, так XCOM традиционно "играет" на правильной оценке рисков и минимизации потерь).
Исторически, жанры компьютерных стратегий и тактик — всегда о противостоянии, а поэтому я не склонен считать детальность симуляции решаюшим фактором при оценке этого жанра. Решающее — это как раз таки насколько сложно (но при этом возможно) нащупать путь к победе.
Так вам симуляция нужна, или тактика?
Тактике необходим хороший баланс и сильный (или хотя бы превосходящий возможностями) ИИ. А в симуляции — да, достаточно чтоб можно было предпринять 100500 действий (и плевать, что 100498 из них не нужны для победы).
JA2 хорош (очень хорош, причем) как симулятор перестрелок в пошаге. Как тактика он весьма примитивен и прост, и даже попытки его резко усложнить (JA2 Wildfire) не закрыли всех балансовых дыр и просчетов.
Юнит-тесты реактовских компонент — невероятно бессмысленная вещь. Очень недалеко от Enterprise FizzBuzz.
Означает ли, что если юнит-тесты пройдут — наши компоненты будут правильно отображаться и работать? Нет, не означает. Да и принципиально не может, потому что всё, что мы проверили — это делают ли наши компоненты в замокированном DOM некоторые вещи, которые мы ожидаем. От этого и до "компонент правильно отображается и работает" — пропасть, со дна которой на тебя смотрят страшные штуки по имени CSS, browser compatibility, и всё вот это.
Означает ли, что если юнит-тесты не пройдут — наши компоненты не будут правильно отображаться и работать? И опять же нифига: на моей практике на каждую сотню случаев отвала юнит-тестов компонентов примерно штук 5 сообщали о реальных проблемах, а остальные 95 — это "я чего-то поменял в компоненте и теперь мне надо поправить тест, чтоб не падал".
Если у вас очень много свободного времени — тогда да, пишите юнит-тесты на компоненты. Если же нет — тестируйте бизнес-логику, а не появление каких-то там элементов в замокированном DOM.
Это та, в которой в реалтайме можно пройти большинство миссий, просто бегая по карте? И где только отдельные моменты, типа захвата элиенов живьем, требуют некоторого (небольшого) включения головы?
У вас очень странные представления о хорошо сбалансированных тактиках.
Хорошая попытка, но нет. Вещи типа Ведьмака 3 (даже если мы полностью отбросим графон и экшн, как несущественные для этого обсуждения) по проработке ролевой части просто рядом не лежат со старыми фоллаутами, он в разы более объемен при сравнимом (но не в пользу фолов) уровне проработки. Даже если взять чуть более попсовые, но относительно "современные" вещи — биоваровские РПГ окажутся сравнимыми по ролевой части, но куда более проработанными в прочих аспектах (от баланса до графона).
Ну а игр лучше HoMM3 (в разрезе PvE, т.к. аналоги в части PvP особо не востребованы, а потому люди так и играют в HoMM) так и вообще буквально каждая первая (каждая первая из хороших, а не из любых стратегий/тактик вообще), так как упреки, приведенные в статье — полностью справедливы. В ванильном XCOM: EU баланса на порядки больше, чем в HoMM, не говоря уж там про какой-нибудь Long War.
Великолепные старые игры были, главным образом, великолепны на момент своего выхода и последующие сколько-то лет. Понятное дело, что на сегодняшний день те же Фоллауты ничем очень уж сильно не выделяются, а хороший баланс в HoMM3 буквально забежал на минуточку, и сразу вышел. Но во времена их выхода картина мира компьютерных игр была сильно другая.
Уровень дохода вообще не обязан коррелировать с качеством кода. И исключая отдельные места в мире, являющиеся локальными сингулярностями "справедливой вселенной" — он и не коррелирует. Иногда спец, на котором держится вся контора — получает дофига. Иногда буквально "среднерыночно". Иногда посредственного кодера берут на небольшие деньги, а иногда он получает больше всех других программистов в конторе. Просто потому, что пришел в правильный момент, например.
Вы можете с этим бороться, а можете этим пользоваться, вот и вся разница.
"Победить" в моем понимании это влезть в приватное апи, чето там намутить, что изначально не предусматривалось.
Это "переписать", а уж никак не "победить". "Победить" — это дописать.
"Победить" — это взять кривоватый и неудобный инструмент, и таки найти путь применить его, спрятав весь неочевидный код в библиотечные классы и методы (как раз собственно то, о чем они пишут), и выставив наружу уже более интересное и удобное для применения API.
где они делают разные классные штуки именно при помощи Ангуляра
Угу. Типа, "посмотрите, как мы классно победили ангулярский DI, чтоб им наконец-то было достаточно удобно пользоваться". Действительно, и почему же это я говорю, что без него было бы лучше?
Я так и не понял, то ли это "вредные советы", то ли еще что. Скажем первый совет про спред — весьма рабочий. При условии что проект на TS, и типы нормально описаны. А если на JS — то да, это уровень классического // happy debugging!
Это зависит исключительно от вашего тестового окружения. Может и не зарезолвиться. Почти все тестовые обвязки умеют (и обильно практикуют) вмешиваться в "обычные резолвы".
Аналогия совершенно прямая. Вы спросили "что плохого в покрытии веток кода тестами", я вам ответил. Само по себе "покрытие кода" — совершенно бессмысленное занятие, которое само по себе никак не увеличивает качество продукта, ни устойчивость к рефакторингу, ни еще что вы там захотите придумать. Всё, что делает "покрытие кода" — это позволяет вам вывести красивую циферку процента покрытия, которая сама по себе ни о чем не говорит, да и не может.
Rtl никак не относится к e2e и принципиально не может.
Это всегда очень иронично, когда мне пишут абзац голословного текста, сводящийся к "вы ничего не понимаете в N", а сразу за ним — процитированное ^_^
Так что именно решено? Ваши компоненты всегда сверстаны с идеальнейшем соответствием семантике html? Ваши классы никогда не меняются? У вас всегда есть intl с дефолтными болванками текстов? И так в любом вашем проекте?
Если это всё надо, чтоб rtl можно было удобно пользоваться — то я, пожалуй, не буду. В моем мире такая идеальность даже не ночует обычно. А жить как-то надо.
Что вы тогда собрались в них тестировать? Как они взяли кусок данных и обернули его в <span>? А это точно настолько нетривиально, что без тестов никуда?
Какой "описанный подход"?
Мой "стор" выражается ключевым словом class и никаких зависимостей, не относящихся к работе с данными приложения не требует. А к чему вы тут роутер припахали — для меня вообще загадка. Роутер не относится к работе с данными.
Если вы работаете с редаксом — мои соболезнования. Я не работаю и никому не советую этого делать.
Контексты и хуки относятся к реакту, и к работе над данными никогда не привлекаются. Да и не должны. Если вы без реакта не можете написать модельную часть приложения (работу с данными, собссно) — проблема в вас.
Я где-то написал, что юнит-тесты этому противоречат?
Ну так что вы протестируете, взяв реакт-компоненты и rtl?
Море всего, на самом деле, но "своего кода" там будет совсем чуть, а проверять его поведение вы будете внутри вороха абстракций. В то время, как для презентационного слоя единственный критерий прохождения или не прохождения приемки — это чтоб оно всё появилось в реальном браузере и отработало в нем же. Работает ли оно внутри абстракций rtl — это вообще абсолютно никого не волнует.
Да, и поэтому нужно тащить что-то еще для мокирования компонент (типа enzyme), если уж вы вступили на эту кривую дорожку. А то еще и тесты будут не юнит, а хренпоймичто.
Ровно то же плохое, что и в лопаньи пузырьков на пленке. То есть, в общем-то ничего, просто само по себе это совершенно бесполезное занятие, на выходе которого имеем только кучу попорченной пленки. А в нашем случае — гору кода, которая ничего полезного не делает, и будет дальше жрать время на поддержку, пока кто-нибудь её не выкинет из проекта нафиг.
Какое отношение это всё имеет к rtl и статье? Я где-то в своем комментарии сказал, что тестов не надо вообще?
И случаев, когда вам в компоненте нужно столько логики, что её уже неплохо бы тестировать — крайне мало. Но поскольку случаи наворачивания логики внутрь компонента обычно (обычно в идеале, а не обычно когда усилиями традиционных "программистов на реакте" в компонентах оказывается весь код проекта) касается специфических разборок с DOM, то даже и тут тестирование этого на ненастоящем игрушечном DOM — бесполезно.
Если же ваша "внутренняя логика" компонента не совершенно примитивна (взяли уже приготовленные данные, отобразили эти данные как есть) и не написана ради оптимизаций и решения сложных проблем DOM — то ей не место внутри компонента.
Вы статью-то вообще читали? Когда сторона тестов дёргает сторону тестируемого кода через селекторы, завязывающиеся на конкретные теги, классы, или (обоже) тексты — вам неизбежно придётся писать "странные и бесполезные" тесты, которые будут ломаться так сразу, как только в компоненте поменяется хоть что-нибудь по его форме (и плевать, что по смыслу не поменяется ничего).
Давайте будем честными: фоллауты состоят из рельсов тоже примерно полностью (да и вообще любая CRPG), просто маскируют это чуток получше. В обоих фоллаутах один абсолютно невариабельный в ключевых событиях сюжет, два относительно разных способа пройти мейнквест в Ф1, и у каждого из этих разных способов еще по 2-3 пути, отличающихся уж совсем незначительными деталями. А в Ф2 и вовсе один способ. И дополнительные локации, почти все из которых (за исключением очень редких ситуаций) являются целиком "вещью в себе", т.е. ты можешь придти, как-то сделать или не сделать мейнквест локации, и в зависимости от исхода увидеть тот или иной финальный слайд про эту локацию, или… вообще не приходить, от этого ничего в остальном прохождении не меняется.
Разница тут в том, что биоварские РПГ тебя тычут носом в весь имеющийся у них контент (но его тем не менее тоже можно пропускать в очень больших объемах), а фоллаут не тычет. В остальном подход не меняется. И конечно фоллауты очень хорошо поддерживают иллюзию вот этого открытого мира, где много может быть иначе. Но если поковыряться в деталях — неа, не может.
Попробуйте Long War. Ванильные новые XCOM конечно же не слишком сложны (но всё равно на порядки сложнее старых), даже на максимальной сложности.
Не "сложность победы", а "насколько сложно нащупать путь к победе". Это конечно любопытно, что вы второе прочитали как первое, но это совсем не одно и то же.
В игре, где вы побеждаете, если после 1000 подкидываний монетки выпадет 1000 орлов — победить невероятно сложно, а вот "нащупать путь к победе", скорее всего, довольно легко.
Да нет, вы просто смешиваете игры, где соль именно в детальности симуляции (Cataclysm: Dark days ahead как современный яркий пример), и игры, где соль в сложности победы (разными подходами, так XCOM традиционно "играет" на правильной оценке рисков и минимизации потерь).
Исторически, жанры компьютерных стратегий и тактик — всегда о противостоянии, а поэтому я не склонен считать детальность симуляции решаюшим фактором при оценке этого жанра. Решающее — это как раз таки насколько сложно (но при этом возможно) нащупать путь к победе.
Так вам симуляция нужна, или тактика?
Тактике необходим хороший баланс и сильный (или хотя бы превосходящий возможностями) ИИ. А в симуляции — да, достаточно чтоб можно было предпринять 100500 действий (и плевать, что 100498 из них не нужны для победы).
JA2 хорош (очень хорош, причем) как симулятор перестрелок в пошаге. Как тактика он весьма примитивен и прост, и даже попытки его резко усложнить (JA2 Wildfire) не закрыли всех балансовых дыр и просчетов.
Юнит-тесты реактовских компонент — невероятно бессмысленная вещь. Очень недалеко от Enterprise FizzBuzz.
Означает ли, что если юнит-тесты пройдут — наши компоненты будут правильно отображаться и работать? Нет, не означает. Да и принципиально не может, потому что всё, что мы проверили — это делают ли наши компоненты в замокированном DOM некоторые вещи, которые мы ожидаем. От этого и до "компонент правильно отображается и работает" — пропасть, со дна которой на тебя смотрят страшные штуки по имени CSS, browser compatibility, и всё вот это.
Означает ли, что если юнит-тесты не пройдут — наши компоненты не будут правильно отображаться и работать? И опять же нифига: на моей практике на каждую сотню случаев отвала юнит-тестов компонентов примерно штук 5 сообщали о реальных проблемах, а остальные 95 — это "я чего-то поменял в компоненте и теперь мне надо поправить тест, чтоб не падал".
Если у вас очень много свободного времени — тогда да, пишите юнит-тесты на компоненты. Если же нет — тестируйте бизнес-логику, а не появление каких-то там элементов в замокированном DOM.
Это та, в которой в реалтайме можно пройти большинство миссий, просто бегая по карте? И где только отдельные моменты, типа захвата элиенов живьем, требуют некоторого (небольшого) включения головы?
У вас очень странные представления о хорошо сбалансированных тактиках.
Хорошая попытка, но нет. Вещи типа Ведьмака 3 (даже если мы полностью отбросим графон и экшн, как несущественные для этого обсуждения) по проработке ролевой части просто рядом не лежат со старыми фоллаутами, он в разы более объемен при сравнимом (но не в пользу фолов) уровне проработки. Даже если взять чуть более попсовые, но относительно "современные" вещи — биоваровские РПГ окажутся сравнимыми по ролевой части, но куда более проработанными в прочих аспектах (от баланса до графона).
Ну а игр лучше HoMM3 (в разрезе PvE, т.к. аналоги в части PvP особо не востребованы, а потому люди так и играют в HoMM) так и вообще буквально каждая первая (каждая первая из хороших, а не из любых стратегий/тактик вообще), так как упреки, приведенные в статье — полностью справедливы. В ванильном XCOM: EU баланса на порядки больше, чем в HoMM, не говоря уж там про какой-нибудь Long War.
Почему вы отличные игры прошлых времен сравниваете с "многими" современными, а не с лучшими современными?
Великолепные старые игры были, главным образом, великолепны на момент своего выхода и последующие сколько-то лет. Понятное дело, что на сегодняшний день те же Фоллауты ничем очень уж сильно не выделяются, а хороший баланс в HoMM3 буквально забежал на минуточку, и сразу вышел. Но во времена их выхода картина мира компьютерных игр была сильно другая.
Рыб надо брать, рыб — тоже работают за двоих и при этом молча! Идеальный исполнитель!
Уровень дохода вообще не обязан коррелировать с качеством кода. И исключая отдельные места в мире, являющиеся локальными сингулярностями "справедливой вселенной" — он и не коррелирует. Иногда спец, на котором держится вся контора — получает дофига. Иногда буквально "среднерыночно". Иногда посредственного кодера берут на небольшие деньги, а иногда он получает больше всех других программистов в конторе. Просто потому, что пришел в правильный момент, например.
Вы можете с этим бороться, а можете этим пользоваться, вот и вся разница.
Это "переписать", а уж никак не "победить". "Победить" — это дописать.
"Победить" — это взять кривоватый и неудобный инструмент, и таки найти путь применить его, спрятав весь неочевидный код в библиотечные классы и методы (как раз собственно то, о чем они пишут), и выставив наружу уже более интересное и удобное для применения API.
Я про них и пишу.
Угу. Типа, "посмотрите, как мы классно победили ангулярский DI, чтоб им наконец-то было достаточно удобно пользоваться". Действительно, и почему же это я говорю, что без него было бы лучше?
Я так и не понял, то ли это "вредные советы", то ли еще что. Скажем первый совет про спред — весьма рабочий. При условии что проект на TS, и типы нормально описаны. А если на JS — то да, это уровень классического // happy debugging!