Что Вы, в итоге, имеете ввиду под "это"? Паттерны больше про ремесло, чем про науку. По методикам (самым разным) исследований полно. Возьмите любой ВУЗ с профильными предметами - есть диссертации, дипломные и всякие остальные квалификационные работы.
Из очевидного - в сравнении. В исследовании, которое я упомянул в статье ("An Initial Investigation of Test Driven Development in Industry") сравнивают проекты выстроенные вокруг unit-тестов, с проектами на "ручной тяге", если правильно помню.
Из неочевидного - к примеру, через риски. Но, скажу честно, в это я не умею. Не участвовал в проектах, где риск-менеджмент являлся бы обязательным. Может быть кто-то из читателей имеет подобный опыт?
На всякий случай - я не адепт TDD. Я адепт адекватных подходов к каждому конкретному случаю. А теперь про видео.
Спикер приводит в пример "парадокс воронов", и при этом на протяжении всего видео использует "подмену тезиса". Если честно, после первого случая хотелось закрыть видео, но пересилил это желание. И пожалел.
Адепт TDD не редко думает, что падение теста на явно некорректном коде может хоть что-то сказать о том, будет ли тест падать на коде, который похож на корректный.
Что тут спикер имел ввиду крайне сложно понять. Что-то типа: кто-то думает, что если тест упал на некорректном коде, то совсем не факт, что он не упадет на корректном? Тест отражает желаемое поведение модуля. Если тест упал на "корректном" коде, то каким образом выясняется "корректность"?
Используя TDD, сможете написать первый "красный" тест, другой, третий. Но довольно быстро вы столкнетесь с ситуацией, что вы уже написали код, который уже удовлетворяет всем тест кейсам, но тестов Вы написали меньше половины. И эта ситуация, к сожалению, неизбежна.
Складывается впечатление, что спикер видит смысл TDD в написании "красных" тестов. Нужны не "красные" тесты, а тесты, которые показывают какое поведение модуля мы ожидаем. Какую конкретно ситуацию рассматривает спикер? При использовании TDD такая ситуация возможна при рефакторинге legacy-кода. Так и в чем проблема того, что тест сразу "зеленый"? В том что этот код работает так как мы ожидали? Понять решительно невозможно. И исходя из этого спикер делает вывод: "Для обеспечения качества, мы вынуждены явно нарушать основную идею TDD - сначала тест, потом код.". Феноменально.
... ограничившись лишь минимальной реализацией, достаточной нам для прохождения тестов. Следовательно, мы зачастую будем писать явно некорректный код, который на следующей итерации будет отправляться в мусорную корзину.
Да из чего "следовательно"?!
Почему минимальная реализация это некорректный код? Почему минимальная реализация не будет расширяться, а будет "отправляться в мусорную корзину"?
Однако, всё ещё остаётся довольно высокая вероятность (того что) в любой момент столкнуться с такой ситуацией, что очередное изменение кода сломает все ваши тесты.
Очередное изменение сломает тесты. Это точно про TDD? Может сначала тесты изменим, а после код править будем? Нет? Ну, ладно.
Как было отмечено ранее, применение TDD в общем случае скорее вредно, чем полезно.
Какой общий случай? Где отмечено-то? Спикер всё видео в неявном виде обсуждает ситуацию рефакторинга, а не разработки нового кода.
Извините, моё мнение о видео можно кратко описать: кг/ам
Да это не особо я их так называю, а Рой Ошеров. Я всего лишь скромно придерживаюсь его точки зрения.
Можно назвать такие unit-тесты компонентными. Можно назвать интеграционные тесты sociable-unit-тестами. Главное правильно выбирать подход к тестированию.
Не уверен, что правильно понял, что значит "хуже". Не так эффективны?
Не покрывайте тривиальный код unit-тестами. Такой код может быть как на back-end, так и на front-end. В современных приложениях его больше на front-end. Это всего лишь значит, что тут нужно меньше тестов.
Почему же ложную? Исходя из вашего примера уверенность вполне обоснованная. Только она ограничивается модулями, которые покрыты тестами. Мы можем быть уверены в модуле A.
Когда исполнятся интеграционные тесты (они ведь есть, правда?) - мы увидим дефект. Во время фикса, я надеюсь, разработчик покроет злосчастный "B" unit-тестами. Проблема решена.
Понимаю, но тесты с реальными зависимостями теряют такие нужные (для unit-тестов) качества как консистентность и скорость исполнения. Исходя из этого, их уже нельзя считать вполне unit-тестами.
Почему в приведенном примере моки бесполезны? Потому что нужно проверить именно взаимодействие с БД? Тогда это по определению интеграционный тест. Ну, или тест совместимости (Interoperability).
В любом случае - замечательно, что такие тесты у Вас есть. Пусть они как угодно называются - главное, что Вы думаете о качестве продукта )
Вполне вежливо, спасибо ) Я рад, что на Ваших проектах всегда есть разработчики, которые понимают как и где писать unit-тесты. К сожалению, так не везде.
Непонятно, что покрывать unit-тестами. Кажется, что все методы довольно просты, и в их логике трудно совершить ошибку (допустить дефект).
Нет опыта разработки unit-тестов на front-end. На текущем проекте нет в этом необходимости.
Если разбирать проблемы по частям, то...
Покрывать unit-тестами на фронте нужно алгоритмы (или код с несколькими зависимостями), и то, что планируется к рефакторингу.
К примеру, на одном из моих проектов, ещё с этапа mvp "висит" часть агрегации данных (собственно, алгоритм), которые пришли с бэка, на фронте. Сейчас это проверяется функциональными UI-автотестами. А значит, проверка занимает больше времени, требует ресурсы на конфигурацию окружения, не такая стабильная как могла бы быть, и т.д. И, разумеется, никто это рефакторить не хочет: нет unit-тестов == код legacy == никто не хочет работать с legacy. Если кто-то бы захотел, то, как вариант, стоит покрыть код unit-тестами, и вперед - red-green-refactor.
Про отсутствие опыта. Ты же знаешь о jest. Нечего покрыть на текущем проекте из-за простоты дизайна? Не думаю, что стоит ждать подходящий проект, где можно будет научиться. Обычно, на таких проектах уже нужно уметь. Создай свой проект, под эти нужды. Начни это делать, и, со временем, количество проделанной работы точно приведет к качеству "умение в unit-тесты". Уверен, что у тебя получится.
Вот количество e2e тестов в проектах моей компании, и побудило меня (в том числе) написать статью.
Абсолютное большинство проектов имеют общую черту - простой интерфейс пользователя, и сложные, временами запутанные, алгоритмы на сервисном слое.
Отсутствие unit-тестов не позволяет, соответственно, проводить интеграционное тестирование инкрементным методом - в модулях-то мы не уверены.
И сейчас, в основном, тестирование вынуждено концентрирует усилия на e2e проверках, и на интеграционном тестировании с подходом big bang. Приводит это к огромным тестовым наборам из e2e кейсов, а значит к очень дорогому и неповоротливому тестированию. Короче, тема для отдельного и нудного повествования. И закончится всё холиваром )
Автоматизированный код... неудачно подобрал сокращение, спасибо. Имеется ввиду код для задач автоматизации.
Да, Вы правы. Независимость сама по себе не нужна - только для обеспечения качества консистентности. Для этого тест быть независимым от окружения, состояния тестируемого объекта, и от других тестов.
Да, конечно, unit-тесты пишут разработчики. И они могут обратиться к QA с вопросом о конкретных кейсах. А QA подскажут - каким минимальным набором проверок можно покрыть конкретные функции.
Привет. Как раз в книге по которой статейку написал, есть глава про "рост затрат времени". Очень рекомендую. Если кратко - растет время на разработку, но снижается время на поставку.
Ищешь, что тестировать unit-тестами на фронте? Могу запилить небольшую статью на эту тему. Подтверди, плиз, что я правильно понял.
Эээммм... А к кому вопрос? )
Слушайте советы!
Что Вы, в итоге, имеете ввиду под "это"? Паттерны больше про ремесло, чем про науку. По методикам (самым разным) исследований полно. Возьмите любой ВУЗ с профильными предметами - есть диссертации, дипломные и всякие остальные квалификационные работы.
Из очевидного - в сравнении. В исследовании, которое я упомянул в статье ("An Initial Investigation of Test Driven Development in Industry") сравнивают проекты выстроенные вокруг unit-тестов, с проектами на "ручной тяге", если правильно помню.
Из неочевидного - к примеру, через риски. Но, скажу честно, в это я не умею. Не участвовал в проектах, где риск-менеджмент являлся бы обязательным. Может быть кто-то из читателей имеет подобный опыт?
На всякий случай - я не адепт TDD. Я адепт адекватных подходов к каждому конкретному случаю. А теперь про видео.
Спикер приводит в пример "парадокс воронов", и при этом на протяжении всего видео использует "подмену тезиса". Если честно, после первого случая хотелось закрыть видео, но пересилил это желание. И пожалел.
Что тут спикер имел ввиду крайне сложно понять. Что-то типа: кто-то думает, что если тест упал на некорректном коде, то совсем не факт, что он не упадет на корректном? Тест отражает желаемое поведение модуля. Если тест упал на "корректном" коде, то каким образом выясняется "корректность"?
Складывается впечатление, что спикер видит смысл TDD в написании "красных" тестов. Нужны не "красные" тесты, а тесты, которые показывают какое поведение модуля мы ожидаем.
Какую конкретно ситуацию рассматривает спикер? При использовании TDD такая ситуация возможна при рефакторинге legacy-кода. Так и в чем проблема того, что тест сразу "зеленый"? В том что этот код работает так как мы ожидали? Понять решительно невозможно.
И исходя из этого спикер делает вывод: "Для обеспечения качества, мы вынуждены явно нарушать основную идею TDD - сначала тест, потом код.". Феноменально.
Почему минимальная реализация это некорректный код? Почему минимальная реализация не будет расширяться, а будет "отправляться в мусорную корзину"?
Очередное изменение сломает тесты. Это точно про TDD? Может сначала тесты изменим, а после код править будем? Нет? Ну, ладно.
Какой общий случай? Где отмечено-то? Спикер всё видео в неявном виде обсуждает ситуацию рефакторинга, а не разработки нового кода.
Извините, моё мнение о видео можно кратко описать: кг/ам
Повторюсь, смыслом unit-тесты наделяет сложность кода, который они покрывают. Если код тривиален, то его где угодно покрывать не имеет смысла.
Если занимается бесполезным трудом, то, разумеется, ROI будет низким.
Да это не особо я их так называю, а Рой Ошеров. Я всего лишь скромно придерживаюсь его точки зрения.
Можно назвать такие unit-тесты компонентными. Можно назвать интеграционные тесты sociable-unit-тестами. Главное правильно выбирать подход к тестированию.
Спасибо за видео - ознакомлюсь.
Не уверен, что правильно понял, что значит "хуже". Не так эффективны?
Не покрывайте тривиальный код unit-тестами. Такой код может быть как на back-end, так и на front-end. В современных приложениях его больше на front-end. Это всего лишь значит, что тут нужно меньше тестов.
Почему же ложную? Исходя из вашего примера уверенность вполне обоснованная. Только она ограничивается модулями, которые покрыты тестами. Мы можем быть уверены в модуле A.
Когда исполнятся интеграционные тесты (они ведь есть, правда?) - мы увидим дефект. Во время фикса, я надеюсь, разработчик покроет злосчастный "B" unit-тестами. Проблема решена.
Понимаю, но тесты с реальными зависимостями теряют такие нужные (для unit-тестов) качества как консистентность и скорость исполнения. Исходя из этого, их уже нельзя считать вполне unit-тестами.
Почему в приведенном примере моки бесполезны? Потому что нужно проверить именно взаимодействие с БД? Тогда это по определению интеграционный тест. Ну, или тест совместимости (Interoperability).
В любом случае - замечательно, что такие тесты у Вас есть. Пусть они как угодно называются - главное, что Вы думаете о качестве продукта )
Если говорите о "Clean Code", то нет. Статья по книге "The art of unit testing".
Вполне вежливо, спасибо ) Я рад, что на Ваших проектах всегда есть разработчики, которые понимают как и где писать unit-тесты. К сожалению, так не везде.
Я с Вами не согласен. Test Containers нужны для интеграционного тестирования. Для unit-тестов лучше не прибегать к внешним зависимостям.
Как понимаю есть пара сложностей:
Непонятно, что покрывать unit-тестами. Кажется, что все методы довольно просты, и в их логике трудно совершить ошибку (допустить дефект).
Нет опыта разработки unit-тестов на front-end. На текущем проекте нет в этом необходимости.
Если разбирать проблемы по частям, то...
Покрывать unit-тестами на фронте нужно алгоритмы (или код с несколькими зависимостями), и то, что планируется к рефакторингу.
К примеру, на одном из моих проектов, ещё с этапа mvp "висит" часть агрегации данных (собственно, алгоритм), которые пришли с бэка, на фронте. Сейчас это проверяется функциональными UI-автотестами. А значит, проверка занимает больше времени, требует ресурсы на конфигурацию окружения, не такая стабильная как могла бы быть, и т.д. И, разумеется, никто это рефакторить не хочет: нет unit-тестов == код legacy == никто не хочет работать с legacy. Если кто-то бы захотел, то, как вариант, стоит покрыть код unit-тестами, и вперед - red-green-refactor.
Про отсутствие опыта. Ты же знаешь о jest. Нечего покрыть на текущем проекте из-за простоты дизайна? Не думаю, что стоит ждать подходящий проект, где можно будет научиться. Обычно, на таких проектах уже нужно уметь. Создай свой проект, под эти нужды. Начни это делать, и, со временем, количество проделанной работы точно приведет к качеству "умение в unit-тесты". Уверен, что у тебя получится.
О вкусах не спорят ) Соглашусь с Вами.
Вот количество e2e тестов в проектах моей компании, и побудило меня (в том числе) написать статью.
Абсолютное большинство проектов имеют общую черту - простой интерфейс пользователя, и сложные, временами запутанные, алгоритмы на сервисном слое.
Отсутствие unit-тестов не позволяет, соответственно, проводить интеграционное тестирование инкрементным методом - в модулях-то мы не уверены.
И сейчас, в основном, тестирование вынуждено концентрирует усилия на e2e проверках, и на интеграционном тестировании с подходом big bang. Приводит это к огромным тестовым наборам из e2e кейсов, а значит к очень дорогому и неповоротливому тестированию. Короче, тема для отдельного и нудного повествования. И закончится всё холиваром )
Автоматизированный код... неудачно подобрал сокращение, спасибо. Имеется ввиду код для задач автоматизации.
Да, Вы правы. Независимость сама по себе не нужна - только для обеспечения качества консистентности. Для этого тест быть независимым от окружения, состояния тестируемого объекта, и от других тестов.
Да, конечно, unit-тесты пишут разработчики. И они могут обратиться к QA с вопросом о конкретных кейсах. А QA подскажут - каким минимальным набором проверок можно покрыть конкретные функции.
Привет. Как раз в книге по которой статейку написал, есть глава про "рост затрат времени". Очень рекомендую. Если кратко - растет время на разработку, но снижается время на поставку.
Ищешь, что тестировать unit-тестами на фронте? Могу запилить небольшую статью на эту тему. Подтверди, плиз, что я правильно понял.