Всем привет! Меня зовут Иван. И я решил завести этот канал под новый год, чтоб подвести итоги года 🤡
Шутка-шутка.
Уже 13 лет япрограммирую перекладываю жсоны, а в свободное время занимаюсь скалолазанием и перекладыванием жсонов. За это время, у меня накопился определенный багаж опыта и знаний в этой теме, которыми бы я хотел делиться. А еще, я часто бомблю в дискуссиях на тему программирования. Но собираюсь покончить с этой пагубной привычкой! (тут возможен пиздеж)
Поэтому я завел этот канал, где планирую
• Постить всякие мысли по поводу разработки ПО
• Делиться техническими заметками на тему программирования
• Читать ваши комментари, и стараться не бомбить (робота над собой)
• Постить мемасы и шутейки
Так шо подписывайтесь пожалуйста и каментируйте. В свою очередь, обещаю вам не спамить слишком сильно, быть конструктивным и не супер душным ❤️
Шутка-шутка.
Уже 13 лет я
Поэтому я завел этот канал, где планирую
• Постить всякие мысли по поводу разработки ПО
• Делиться техническими заметками на тему программирования
• Читать ваши комментари, и стараться не бомбить (робота над собой)
• Постить мемасы и шутейки
Так шо подписывайтесь пожалуйста и каментируйте. В свою очередь, обещаю вам не спамить слишком сильно, быть конструктивным и не супер душным ❤️
❤13🔥3👨💻3🗿2👾2💩1
Чуть меньше года прошло с моего митапа про юнит тестирование. И вы спросите "Поменялось ли что-то с тех самых пор? Стал ли ты писать тесты по-другому? Как у тебя вообще дела? " А я вам отвечу "Да, кое-что поменялось. Да, стал писать тесты немного по-другому". Сейчас расскажу про это поподробнее. Но прежде всего, давайте напомню основные тезисы с митапа.
Существуют две школы юнит тестирования, основные отличия между которым заключается в том, что именно мы заменяем тестовыми заглушками (моками):
* Классическая школа (КШ) - мокаем только внешние зависимости (кроме базы данных)
* Лондонская школа (ЛШ) - мокаем все зависимости
Соответственно, юнит это:
* Единица поведения в КШ
* Единица кода (метод или функция) в ЛШ
Митап строился по книге Владимира Хорикова "Принципы юнит тестирования". Книгу рекомендую к прочтению. В книге В. Хориков призывает писать тесты с ипользованием КШ. Я с этим мнением не согласен. На митапе я больше тяготел к ЛШ. Про плюсы и минусы обоих школ можно кратко посмотреть в моей презентации.
ЛШ позволяет более простым способом обеспечить полное покрытие тестами (формально). Если есть две зависимости A и B с n и m возможными исходами соотвественно, то в ЛШ мы пишем n + m тестов. В КШ нам прошлось бы написать n * m тестов. Разумеется, если зависимостей больше, то это произведение будет стремительно расти. Лондонская школа дает ощущение достижимости полного покрытия. Даже если ты не ставишь целью достичь 100% покрытия, ты все равно пишешь и пишешь эти тесты. Потому что можешь.
КШ даже не ставит перед тобой подобных задач. Потому что это недостижимо и неважно. Просто покрываем позитивные пути, и, если будет желание, парочку самых важных кейсов с ошибками.
Теперь о том, как изменилось мнение касательно юнит тестов.
Основным минусом ЛШ для меня стало время. В какой-то момент я стал понимать, что не фичи пилю, а тесты. Причем, те баги, что я находил с помощью тестов, могли бы быть найдены и с менее полным покрытием. В итоге я стал сочетать обе школы. Знаете, это будто какой-то переход в зрелость: тебе дают два противоположных подхода, но вместо выбора одного из них, ты начинаешь использовать их как инструменты и выбирать соответствующий под ситуацию.
Приведу (абстрактный) пример из практики. Допустим у вас есть подсистема, которая определяет правила доступа к контенту с очень сложной бизнес логикой. Эта подсистема может состоять из кучи внутренних юнитов. Вместе с тем, есть части системы, которые используют эту подсистему: показ контента, генерация отчетов, подписки и прочее. Тогда наверное имеет смысл использовать КШ для подсистемы правил, а для клиентских частей оставить ЛШ, верно?
Неверно! Это зависит от устройства подсистемы правил доступа. В некоторых случаях будет достаточно сделать именно так. Но, допустим, эта подсистема просто дергает другие подподсистемы, а итоговый результат - это логическое сложение результатов. В этом случае может иметь смысл оставить тестирование с помощью ЛШ, а как раз таки внутренние подподсистемы протестировать классически.
Как определить, где какую школу использовать? К сожалению простого ответа здесь дать не смогу. Как и многое в разработке ПО, выбор школы тестирования - это выбор наиболее компромиссного варианта, основанный на вашем опыте. В данный момент я делаю выбор так, чтоб минимизировать время их написания и количество кода в тестах. В конечном итоге это выливается в вопрос: какая школа обеспечит более простую преподготовку данных при схожем покрытии?
Штош, получилось душновато. Соррян)
Поделитесь в каментах, пишите ли вы юнит тесты? какой подход используете?
Существуют две школы юнит тестирования, основные отличия между которым заключается в том, что именно мы заменяем тестовыми заглушками (моками):
* Классическая школа (КШ) - мокаем только внешние зависимости (кроме базы данных)
* Лондонская школа (ЛШ) - мокаем все зависимости
Соответственно, юнит это:
* Единица поведения в КШ
* Единица кода (метод или функция) в ЛШ
Митап строился по книге Владимира Хорикова "Принципы юнит тестирования". Книгу рекомендую к прочтению. В книге В. Хориков призывает писать тесты с ипользованием КШ. Я с этим мнением не согласен. На митапе я больше тяготел к ЛШ. Про плюсы и минусы обоих школ можно кратко посмотреть в моей презентации.
ЛШ позволяет более простым способом обеспечить полное покрытие тестами (формально). Если есть две зависимости A и B с n и m возможными исходами соотвественно, то в ЛШ мы пишем n + m тестов. В КШ нам прошлось бы написать n * m тестов. Разумеется, если зависимостей больше, то это произведение будет стремительно расти. Лондонская школа дает ощущение достижимости полного покрытия. Даже если ты не ставишь целью достичь 100% покрытия, ты все равно пишешь и пишешь эти тесты. Потому что можешь.
КШ даже не ставит перед тобой подобных задач. Потому что это недостижимо и неважно. Просто покрываем позитивные пути, и, если будет желание, парочку самых важных кейсов с ошибками.
Теперь о том, как изменилось мнение касательно юнит тестов.
Основным минусом ЛШ для меня стало время. В какой-то момент я стал понимать, что не фичи пилю, а тесты. Причем, те баги, что я находил с помощью тестов, могли бы быть найдены и с менее полным покрытием. В итоге я стал сочетать обе школы. Знаете, это будто какой-то переход в зрелость: тебе дают два противоположных подхода, но вместо выбора одного из них, ты начинаешь использовать их как инструменты и выбирать соответствующий под ситуацию.
Приведу (абстрактный) пример из практики. Допустим у вас есть подсистема, которая определяет правила доступа к контенту с очень сложной бизнес логикой. Эта подсистема может состоять из кучи внутренних юнитов. Вместе с тем, есть части системы, которые используют эту подсистему: показ контента, генерация отчетов, подписки и прочее. Тогда наверное имеет смысл использовать КШ для подсистемы правил, а для клиентских частей оставить ЛШ, верно?
Неверно! Это зависит от устройства подсистемы правил доступа. В некоторых случаях будет достаточно сделать именно так. Но, допустим, эта подсистема просто дергает другие подподсистемы, а итоговый результат - это логическое сложение результатов. В этом случае может иметь смысл оставить тестирование с помощью ЛШ, а как раз таки внутренние подподсистемы протестировать классически.
Как определить, где какую школу использовать? К сожалению простого ответа здесь дать не смогу. Как и многое в разработке ПО, выбор школы тестирования - это выбор наиболее компромиссного варианта, основанный на вашем опыте. В данный момент я делаю выбор так, чтоб минимизировать время их написания и количество кода в тестах. В конечном итоге это выливается в вопрос: какая школа обеспечит более простую преподготовку данных при схожем покрытии?
Штош, получилось душновато. Соррян)
Поделитесь в каментах, пишите ли вы юнит тесты? какой подход используете?
❤6🏆3❤🔥2👍2🌭2💊2⚡1
