как и не важен уровень детализации: это можно и про функцию говорить, и про класс, и про либу, и про апликейшн в целом

ну вообще-то они должны тебе помогать находить что не так)

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

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

посмотри видяшку что я скинул

потом поговорим

Зачем мне твою видяшка, я тебе про свой опыт говорю. И фичи пилим быстро без переписывания тестов постоянного.

https://www.destroyallsoftware.com/talks/boundaries

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

ну это может работать на небольшом числе случаев и быстрой инфраструктуре

и вот эту видяшку еще

да может и без тестов работать)

как вообще возможен рефакторинг без тестов?

и, я вам скажу, иногда намного лучше, чем с тестами

ну это может работать на небольшом числе случаев и быстрой инфраструктуре

Так 2018 на дворе, докеры-х##ры, тест-контейнеры - вот это все

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

как вообще возможен рефакторинг без тестов?

На динамических языках типа clojure/python наверное никак, на стат типизированных - типы многое решают.

Так 2018 на дворе, докеры-х##ры, тест-контейнеры - вот это все

нунун, особенно на микросервисах очень просто

Так 2018 на дворе, докеры-х##ры, тест-контейнеры - вот это все

это очень медленно

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

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

CI + билд сервер = ноу проблем

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

CI + билд сервер = ноу проблем

медленно

при разработке хочется получать фидбек на изменениях очень быстро

убрал какой-то кусок и хочу понять, сломал я чето или нет как можно быстрее

1. ошибки типов 2. ошибки юнит-тестов 3. ошибки интеграционных тестов 4. ошибки e2e тестов

я тоже хочу получить годовую ЗП в начале года, но приходится терпеть

ужас просто)

ну если болит, то уже 40 лет как есть решение это боли, просто юзайте

если не болит, то не надо карго-культом заниматься)

просто это есть и все. Как сборка и компиляция проекта на крестах каких-нибудь. Я уверен, что они тоже хотят фидбэк сразу получать. Но жизнь несправедлива)

не обязательно собирать всё, чтоб проверить маленький кусочек

вот и ответ)

убрал какой-то кусок и хочу понять, сломал я чето или нет как можно быстрее

вот на это

?

Очевидно, что если хочешь быстро - "не обязательно собирать всё, чтоб проверить маленький кусочек". Транслируя в тесты - не обязательно тестировать всё, чтобы проверить маленький кусочек. Смысл один - много кода = долгая сборка / долгие тесты. Это неизбежно.

Очевидно, что если хочешь быстро - "не обязательно собирать всё, чтоб проверить маленький кусочек". Транслируя в тесты - не обязательно тестировать всё, чтобы проверить маленький кусочек. Смысл один - много кода = долгая сборка / долгие тесты. Это неизбежно.

Вопрос в скорости фидбека. Скорость может достигаться изоляцией тестируемого кода

Ох уж ето программирование без снапшот тестов

Проблемы и новые термины там где о тестах даже вспоминать не требуется

Снапшоты особо не решают ни какую проблему из обсуждаемых

Штука хорошая да

Снапшоты особо не решают ни какую проблему из обсуждаемых

Да, конечно

Просто не парят голову

Bddtddhdd is dead is alive пофигу

Ох уж ето программирование без снапшот тестов

Можно ссылочку на статью, а то гугл выдает почему-то "скриншот-тесты для ректа и тп"

Можно ссылочку на статью, а то гугл выдает почему-то "скриншот-тесты для ректа и тп"

https://facebook.github.io/jest/docs/en/snapshot-testing.html

А ну те я правильно понял, что это про фронтенд (хотя идея конечно гуд)

Ещё носик поморщить нужно, ага

?

Я например так тестирую парсеры и грамматики, так как заматчить огромный ast проще чем описывать правила для его проверки

И многое другое

В целом всё, что генерирует однозначную структуру данных гораздо проще тестировать именно так

Стыдно должно быть прозевать новые технологии с мотивом А НУ ЕТО ДЛЯ ФРОНТА ЖЕ

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

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

К тестам, это конкретный служебный код, мок

Хотя конечно смотря насколько сильно абстрагируешься ?

только это стабом называется. а не моком.

Логично, спасибо

только это стабом называется. а не моком.

Мб

только это стабом называется. а не моком.

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

Ну все же согласны что моков надо избегать (по возможности) и пытаться больше делать стабами?

Нууу, не все. Я тут намедни спорил, что это раскрытие реализации в тестах. Кому-то так более удобно

Ну все же согласны что моков надо избегать (по возможности) и пытаться больше делать стабами?

да, потому что моки это связанность а связанность должна быть минимальна.

ну то есть вопрос весь в том что бы как-то контролировать сайд эффекты

Зачем мне твою видяшка, я тебе про свой опыт говорю. И фичи пилим быстро без переписывания тестов постоянного.

+1

моки нужны только для тестирования сайд эффектов, и если тебе эти сайд эффекты проверять не надо, то не надо мокать.

Зачем мне твою видяшка, я тебе про свой опыт говорю. И фичи пилим быстро без переписывания тестов постоянного.

я не знаю какой у тебя опыт, но что-то мне подсказывает что... видяшка тебе эта не помешает)

(ok ok гляну (ну те добавлю в watch later))

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

Этот консультант говорит как политик -- все очень красиво, но к реальности мало применимо.

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

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

Этот консультант говорит как политик -- все очень красиво, но к реальности мало применимо.

ты это говоришь как человек который пытался? или просто?

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

может быть вопрос в том как ты границы проводишь? и как ты выбираешь что покрывать юнитами а что покроется e2e?

в целом идею можно свести к контрактным тестам (которые нужны особенно на границах модулей) и к тому что бы уменьшать количество зависимостей. И если у тебя не выходит уменьшить количество зависимостей - перераспределить все так что бы был метод-сценарий в котором нет логики и только последовательность действий.

ну то есть, все это не рокет сайнс

и да - важный аспект - он ничего не говорил о том что e2e/приемочные тесты не нужны, только интеграционные которые подразумевают тестирование какой-то технической фигни (вроде потещу я сервис и сущность)

и да, никто не говорил что с такими идеями можно просто взять подходы к которым все привыкли и просто "делать так". Так оно не работает. И да, я из-за этого видоса полес в event-driven архитектуры.

А до property-based еще не дошел?

Сугубо опциональный подход

может быть вопрос в том как ты границы проводишь? и как ты выбираешь что покрывать юнитами а что покроется e2e?

Я не могу с первого раза провести границы "правильно". И со второго тоже. Вы можете? Я пишу тест на том уровне абстракции, на котором в данный момент понимаю задачу, а потом по необходимости спускаюсь дальше. Если перед началом работы над задачей мне известно только то, что я могу решить ее с помощью "технической фигни", то я буду писать тест на техническую фигню. И это нормально. Может я никогда и не напишу "настоящий unit-тест" для этой задачи, потому что буду уверен в ее работоспособности и без него.

Я не могу с первого раза провести границы "правильно". И со второго тоже. Вы можете? Я пишу тест на том уровне абстракции, на котором в данный момент понимаю задачу, а потом по необходимости спускаюсь дальше. Если перед началом работы над задачей мне известно только то, что я могу решить ее с помощью "технической фигни", то я буду писать тест на техническую фигню. И это нормально. Может я никогда и не напишу "настоящий unit-тест" для этой задачи, потому что буду уверен в ее работоспособности и без него.

я тоже не могу, но я могу границы менять, да и тесты хорошо помогают эту границы определять (думать). Контракты мы проектируем все же исходя из нужд клиентского кода, и эти нужны вполне себе можно описать, так? Если так - нет проблем сделать тест контракта и в соответствии с этим же контрактом тестировать наш клиентский код закрыв его стабами/моками. Более того, ты так можешь проектировать сам контракт, когда ты задаешь требуемое твоей зависимости поведение и переходишь к имплементации контракта этого уже после того как разберешься как оно должно работать.

> Может я никогда и не напишу "настоящий unit-тест" для этой задачи, потому что буду уверен в ее работоспособности и без него. настоящий unit test это не сильвер булет, это инструмент позволяющий минимизировать фидбэк луп, ты должен осознавать недостатки этого инструмента (чувствительность к качеству кода, выбранным границам и связанности) и если ты выбираешь путь "забить на связанность пока не разберусь" то юнит тесты тебе мало чем помогут.

В этом нет ничего плохого, но думать что "у всех наверное так" тоже чет как-то плохая идея.

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

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

ты конечно под моком сущности имел ввиду какой-то более простой фейк)

dummy там или stub если прям совсем сложно

не, именно мок сущности)

ну мол... у тебя есть сервис который дергает метод сущности, и сущность я замокаю

не, именно мок сущности)

фига ты дерзкий

т.е. ты должен будешь знать какой именно метод сущности дергает этот сервис?

какието таксебе тесты

т.е. ты должен будешь знать какой именно метод сущности дергает этот сервис?

да, потому моков надо поменьше)

какието таксебе тесты

ох блин... как же с вами тяжело

окей, сервис через дабл диспатч в сущность)

и сервис замокаю

ООП и моки - что может быть прекраснее ? https://twitter.com/rabbitonweb/status/918473231216136192

ООП и моки - что может быть прекраснее ? https://twitter.com/rabbitonweb/status/918473231216136192

когда у тебя мок вызывает другой мок то скорее всего это стабы и нарушение LoD

есть еще неплохая статья на эту тему:

http://blog.thecodewhisperer.com/permalink/beyond-mock-objects

ООП и моки - что может быть прекраснее ? https://twitter.com/rabbitonweb/status/918473231216136192

Хорошо, что в ФП нет таких проблем