VK
так это уже интеграционный тест и есть, если api мокать. в этом случае мне проще сам хук без UI тестировать
Это никак не гарантирует, что он работает хорошо в компонентах же
Size: a a a
2021 March 03
RU
так это уже интеграционный тест и есть, если api мокать. в этом случае мне проще сам хук без UI тестировать
если хук - самостоятельная реиспользуемая единица, можно его в изоляции тестировать
RU
я не зря там статью выше скинул Кента. интеграционные тесты дают наибольшее соотношение профит/затраты
VP
Компонент - это черный ящик, это и есть ваш модуль для юнит тестирования, то, что он использует какие-то хуки - его дело
с каких пор?
компонент - это верстка, не более. Захочу - могу то же самое хоть в консоли делать, но функциональность должна быть +/- та же (я не про кнопконажимание сейчас)
компонент - это верстка, не более. Захочу - могу то же самое хоть в консоли делать, но функциональность должна быть +/- та же (я не про кнопконажимание сейчас)
VK
с каких пор?
компонент - это верстка, не более. Захочу - могу то же самое хоть в консоли делать, но функциональность должна быть +/- та же (я не про кнопконажимание сейчас)
компонент - это верстка, не более. Захочу - могу то же самое хоть в консоли делать, но функциональность должна быть +/- та же (я не про кнопконажимание сейчас)
Не согласен, что компонент - это "просто верстка"
RU
с каких пор?
компонент - это верстка, не более. Захочу - могу то же самое хоть в консоли делать, но функциональность должна быть +/- та же (я не про кнопконажимание сейчас)
компонент - это верстка, не более. Захочу - могу то же самое хоть в консоли делать, но функциональность должна быть +/- та же (я не про кнопконажимание сейчас)
если ты делишь компоненты на "логику" и "верстку", то ничто не мешает тебе делать два компонента: один с хуками, который передает пропы в "тупой"
но так никто не делает, потому что это того просто не стоит, легче тестануть весь компонент в сборе и не заебываться по мелочам
но так никто не делает, потому что это того просто не стоит, легче тестануть весь компонент в сборе и не заебываться по мелочам
RU
надо просто смириться с тем, что в мире реакта нет нормального DI и жить с этим
VK
если ты делишь компоненты на "логику" и "верстку", то ничто не мешает тебе делать два компонента: один с хуками, который передает пропы в "тупой"
но так никто не делает, потому что это того просто не стоит, легче тестануть весь компонент в сборе и не заебываться по мелочам
но так никто не делает, потому что это того просто не стоит, легче тестануть весь компонент в сборе и не заебываться по мелочам
И всё-равно логичнее будет делать уже интеграционный тест из этих двух компонентов потому, что по отдельности они не имеют смысла😁
RU
И всё-равно логичнее будет делать уже интеграционный тест из этих двух компонентов потому, что по отдельности они не имеют смысла😁
не ну чо, версточный компонент можно покрыть вдоль и поперек вариациями пропов
RU
просто это мало что улучшит в плане выгодности тестов
VK
просто это мало что улучшит в плане выгодности тестов
Ну, я об этом
RU
у нас блин есть один кадр в проекте: каждый файл у него имеет свой тест файл, миллиард тестов, где все вокруг мокано-перемокано (селекторы, диспачи), а интеграционных тестов нет
в результате тесты тестят хуйню, потому что они неправильно засетаплены, но это не видно, потому что все замокано
в результате тесты тестят хуйню, потому что они неправильно засетаплены, но это не видно, потому что все замокано
💾K
Народ, подскажите в чем проблема - не срабатывает addToFavorites - не копирует объект велью в selectedList на 54й строке https://codesandbox.io/s/tz-04-react-redux-saga-autocomplete-material-ui-fg65x?file=/src/components/Autocomplete/index.js:1439-1451
VP
И всё-равно логичнее будет делать уже интеграционный тест из этих двух компонентов потому, что по отдельности они не имеют смысла😁
ну например, я могу переписать ту же форму в виде ввода-вывода в терминал, на каком-нибудь ink , но формой она от этого быть не перестанет, со своей же логикой и api.
VK
ну например, я могу переписать ту же форму в виде ввода-вывода в терминал, на каком-нибудь ink , но формой она от этого быть не перестанет, со своей же логикой и api.
Я не понял как это связано с тем, что компонент - юнит, внутрь которого не надо лезть
Если вы это будете делать и полагаться при тестировании на внутреннюю реализацию - вам придется менять тесты каждый раз, когда поменялась эта реализация, а не внешнее апи компонента
Если вы это будете делать и полагаться при тестировании на внутреннюю реализацию - вам придется менять тесты каждый раз, когда поменялась эта реализация, а не внешнее апи компонента
VP
Я не понял как это связано с тем, что компонент - юнит, внутрь которого не надо лезть
Если вы это будете делать и полагаться при тестировании на внутреннюю реализацию - вам придется менять тесты каждый раз, когда поменялась эта реализация, а не внешнее апи компонента
Если вы это будете делать и полагаться при тестировании на внутреннюю реализацию - вам придется менять тесты каждый раз, когда поменялась эта реализация, а не внешнее апи компонента
вот вопрос как раз в том - как при таких условиях должен быть организован компонент на хуках?
чтобы не дублировать логику (переиспользовать её) и тестировать все необходимые состояния?
т.е. очевидно будет что-то про api (отдельный хук), что-то про внешний вид самого компонента (в props или state)
чтобы не дублировать логику (переиспользовать её) и тестировать все необходимые состояния?
т.е. очевидно будет что-то про api (отдельный хук), что-то про внешний вид самого компонента (в props или state)
VK
вот вопрос как раз в том - как при таких условиях должен быть организован компонент на хуках?
чтобы не дублировать логику (переиспользовать её) и тестировать все необходимые состояния?
т.е. очевидно будет что-то про api (отдельный хук), что-то про внешний вид самого компонента (в props или state)
чтобы не дублировать логику (переиспользовать её) и тестировать все необходимые состояния?
т.е. очевидно будет что-то про api (отдельный хук), что-то про внешний вид самого компонента (в props или state)
Вы не должны полагаться на то, что компонент использует конкретный хук, на мой взгляд
Это деталь его внутренней реализации
Это деталь его внутренней реализации
VP
Вы не должны полагаться на то, что компонент использует конкретный хук, на мой взгляд
Это деталь его внутренней реализации
Это деталь его внутренней реализации
> Это деталь его внутренней реализации
вот у меня этот пункт до сих пор вызывает сомнения. логика сайд-эффекта, который ходит в api - деталь реализации кнопки submit?
вот у меня этот пункт до сих пор вызывает сомнения. логика сайд-эффекта, который ходит в api - деталь реализации кнопки submit?
VK
> Это деталь его внутренней реализации
вот у меня этот пункт до сих пор вызывает сомнения. логика сайд-эффекта, который ходит в api - деталь реализации кнопки submit?
вот у меня этот пункт до сих пор вызывает сомнения. логика сайд-эффекта, который ходит в api - деталь реализации кнопки submit?
Кнопка же не ходит в апи)
VK
> Это деталь его внутренней реализации
вот у меня этот пункт до сих пор вызывает сомнения. логика сайд-эффекта, который ходит в api - деталь реализации кнопки submit?
вот у меня этот пункт до сих пор вызывает сомнения. логика сайд-эффекта, который ходит в api - деталь реализации кнопки submit?
Деталь - это то, как именно происходит сабмит, грубо говоря