Comments 92
Это очень мощный и гибкий подход, который тем не менее имеет некоторые недостатки — увеличение сложности, разделение логики, взрывной рост количества типов.
Разделение логики — это достоинство, а не недостаток. А "взрывной рост" наблюдается только там, где при проектировании допущена ошибка.
Тестовый фреймворк предоставляет чистую базу для каждого теста и вы можете создать в ней тестовый сценарий. Это проще и дает больше уверенности в тестах.
Проще, серьезно? "Проще" это только тогда, когда вы для каждого теста создаете нужную ему (и только ему) БД. Но вы представляете себе, насколько это медленно? Поэтому начинают переиспользовать БД между несколькими тестами — а это уже анти-паттерн shared fixture, ну и понеслась...
А еще представьте себе, как просто это делать на билд-агентах при каждом билде.
По крайней мере серверное время намного дешевле времени разработчика.
Это пока разработчик не начинает простаивать, ожидая выполнения чего-то на сервере.
Однако в области тестирования есть очень хорошая альтернатива, которая имеет другой набор преимуществ и недостатков.
Интеграционные тесты — это не альтернатива DI. Интеграционные тесты — это "альтернатива" юнит-тестам; хотя на самом деле, интеграционные тесты — это другой способ тестирования, не способный заменить юнит-тестирование (в обратную сторону тоже верно).
Разделение логики — это достоинство, а не недостаток.
Только если это разделение по ответственности или еще каким-то логическим критериям, а не искусственное — чтобы отделить обращение к базе.
Но вы представляете себе, насколько это медленно? Поэтому начинают переиспользовать БД между несколькими тестами — а это уже анти-паттерн shared fixture, ну и понеслась...
Не надо придумывать того, что не написано — не надо переиспользовать. Не настолько медленно как принято представлять, и есть куда думать, чтобы ускорить.
Интеграционные тесты — это не альтернатива DI.
Альтернатива — то как можно тестировать. А интеграционные тесты это дополнение к unit-тестам.
Только если это разделение по ответственности или еще каким-то логическим критериям, а не искусственное — чтобы отделить обращение к базе.
Обращение к БД — это и есть другая ответственность. Поэтому разделение работы с БД и разделение бизнес-логики — это разделение по ответственности.
Не настолько медленно как принято представлять
Понимаете ли, я опираюсь не на "принято представлять", а на свою ежедневную деятельность, в которой много интеграционных тестов. И они — медленные. На несколько порядков медленее, чем юнит-тесты.
, и есть куда думать, чтобы ускорить.
Например? Потому что в моем опыте "куда ускорить" неизбежно приводит к shared fixture, потому что все рано или поздно упирается во время развертывания чистой БД.
Альтернатива — то как можно тестировать. А интеграционные тесты это дополнение к unit-тестам.
Если дополнение — значит, от DI вы отказаться не сможете. Поэтому и не альтернатива.
Обращение к БД — это и есть другая ответственность. Поэтому разделение работы с БД и разделение бизнес-логики — это разделение по ответственности.
Тут можно поспорить — так принято в .NET, что работа с БД это отдельная ответственность. И я считаю, что во многом из-за того, что по другому не протестировать.
значит, от DI вы отказаться не сможете
Не могу и не хочу, а еще не хочу микроскопом гвозди забивать. У меня в проектах есть логика, которая тестируется и unit-тестами и интеграционными — потому что там ответственно и сложно, а есть где только интеграционные — потому что ну нет там смысла городить весь этот огород.
Тут можно поспорить — так принято в .NET, что работа с БД это отдельная ответственность.
Далеко не только в .net. Вы Фаулера читали?
И я считаю, что во многом из-за того, что по другому не протестировать.
Нет, потому что так сложность меньше.
Читал, и наверное его читали создатели Ruby on Rails, Django, Yii2 и тем не менее выбрали эту схему. Я могу привести мнение DHH (создателя RoR), но может быть лучше не авторитетами давить, а аргументированно критиковать?
И еще раз — я не против DI как такового… я про то, что это часто избыточно.
Читал, и наверное его читали создатели Ruby on Rails, Django, Yii2 и тем не менее выбрали эту схему
Какую "эту"? Слияния логики работы с БД с бизнес-логикой? Или все-таки интеграционного тестирования?
И еще раз — я не против DI как такового… я про то, что это часто избыточно.
А я и не про DI, я про разделение ответственностей. DI — лишь один из способов решения этой задачи.
Слияния логики работы с БД с бизнес-логикой
Да, не разделять их. Иногда это полезно, иногда нет. Я слышу про отделение базы только в контексте двух сценариев: тестирование и гипотетическая смена базы в будущем. Первое можно готовить и по другому, а второе похоже на раннюю оптимизацию.
Иногда полезно разделить бизнес-логику и обращение к данным. Это оправданно с точки зрения потока данных, алгоритмов — и я не имею к этому никаких претензий. Это может быть оправданно даже с позиции тестов — если вам их надо прогнать тычячи. Но этому есть своя цена и надо знать, что есть и альтернативы.
Я слышу про отделение базы только в контексте двух сценариев: тестирование и гипотетическая смена базы в будущем.
Хотя я изначально сказал вам о третьем: это разные ответственности, и их разделение уменьшает сложность кода, ответственного за бизнес-логику.
Увеличение уровней абстракции не факт, что ведет к уменьшению сложности. А очень даже наоборот — вам теперь нужно помнить как работают две сущности и их взаимодействие вместо одной.
Попробуйте пописать на python — довольно неплохо прочищает мозги. Мне C# милее в сотню раз, но свой отпечаток питон оставил.
Увеличение уровней абстракции не факт, что ведет к уменьшению сложности
А никто не говорит, заметим, про увеличение уровней абстракции — можно просто заменить одну абстракцию другой.
А очень даже наоборот — вам теперь нужно помнить как работают две сущности и их взаимодействие вместо одной.
Мне не нужно помнить, как работает DAL, мне нужно знать, какой контракт он выполняет. И это ничем не отличается от того, чтобы помнить, какой контракт поддерживает Entity Framework или ADO.NET.
второе похоже на раннюю оптимизациюВ качестве мимокрокодила отмечу, что когда-то несколько лет назад тоже на это забил, а теперь сильно жалею об этом, так как для перехода с mysql на postgresql оказывается нужным по сути переписать ВСЁ, так и не перехожу до сих пор
Меня бы полностью удовлетворила такая формулировка: есть подход А и Б, вот их плюсы и минусы, решайте, что вам дороже обойдется. К сожалению часто звучит "есть только А, остальное ересь" и это напоминает картинку про PNG и JPEG.
«Проще» это только тогда, когда вы для каждого теста создаете нужную ему (и только ему) БД. Но вы представляете себе, насколько это медленно?
Я не знаю как с этим дела в C#, но в своих проектах на Python и Ruby я только так тесты и писал, всё тестирование с постоянным пересозданием этих баз занимало от нескольких секунд до 5-10 минут в зависимости от размера и оптимизированности проекта, имхо вполне приемлемо
О… как я ждал этого комментария! Ирония в том, что так делают очень многие, но в мире .NET про это мало кто знает и порицается хуже чем goto ))
При каком количестве тестов? БД создается на каждый тест?
Есть много способов как быстро подготовить базу без пересоздания — от использования транзакций (мне не нравится, т.к. хочу тестировать и транзакции тоже), до быстрой очистки.
быстро
Насколько быстро?
Около 600 мс на тест
ALTER DATABASE ... SET RECOVERY SIMPLE
ALTER DATABASE ... SET DELAYED_DURABILITY = FORCED
А если так, то сколько будет? :)
А что здесь происходит? Можно попробовать замерить
Для базы с тестами мы также включаем модель восстановления SIMPLE и отложенную запись в лог DELAYED_DURABILITY = FORCED. В теории это самый простой путь без лишних телодвижений снизить время на подготовку данных для теста.
… а у меня на (юнит-)тест уходит меньше 10 мс. Вот вам и порядок.
Зато при программировании и поддержке цифры меняются местами… там конечно, не будет отличия на порядок, но и время там подороже стоит.
Зато при программировании и поддержке цифры меняются местами…
Почему вдруг?
там конечно, не будет отличия на порядок, но и время там подороже стоит.
Понимаете ли, время, потраченное на выполнение интеграционного теста — это тоже мое время.
Почему вдруг?
Потому что меньше кода, он лучше локализован, тесты максимально приближены к реальной системе (никаких моков) — создал за 10 минут сценарий и погнали.
Потому что меньше кода, он лучше локализован, тесты максимально приближены к реальной системе (никаких моков) — создал за 10 минут сценарий и погнали.
Меньше кода где?
он лучше локализован
Локализация тут вообще ни при чем.
тесты максимально приближены к реальной системе (никаких моков) — создал за 10 минут сценарий и погнали
10 минут — это круто, да. Хотел бы я вам поверить, но не выходит.
А главное, быстрое выполнение тестов — это больше тестов и более частое их выполнение — более раннее обнаружение багов — меньше затрат на саппорт. И упрощение рефакторинга.
полтысячи тестов выполняются за 20 секунд
У вас БД со всем наполнением создается за 40 мс?
(ну и да, я вот тут рядом попинал юнит-тесты, на тест уходит меньше 10 мс — и их еще и можно параллелить)
Сейчас попробовал принудительно создавать по тысяче записей перед каждым тестом (честной неоптимизированной тысячей insert-запросов :) — время выполнения увеличилось до 40 секунд, но я всё ещё считаю это приемлемым
Но всё равно так «в лоб» обычно редко делают, есть куча оптимизаций «пересоздания», в разной степени применимых в каждом конкретном случае)
Сейчас попробовал принудительно создавать по тысяче записей перед каждым тестом (честной неоптимизированной тысячей insert-запросов :) — время выполнения увеличилось до 40 секунд, но я всё ещё считаю это приемлемым
Понимаете ли, в чем дело, у меня тут под боком система, где ~1000 коротких интеграционных тестов идет где-то 40 минут. А начинали с секунд, да.
Там узкое место — это операции с БД. Включая ее инициализацию в корректное (нужное для каждого отдельного теста) состояние.
Самая большая ложка дегтя с интеграционными тестами — это время выполнения, они намного медленнее, но это решаемая проблема.
У Вас БД для каждого теста пересоздается? Если да, то может помочь Instant File Initialization. Либо лучше базу вообще один раз создать, а потом использовать database snapshot для каждого теста. Начиная с 2016 SP1 эта функциональность и в Express редакции доступна.
Как сделать быстрее тут когда-то публиковал про Delayed Durability. Для OLTP нагрузки как раз поможет снизить выполнение Ваших тестов.
База не пересоздается — в ней отключаются constraints и она чистится, получается очень быстро.
Спасибо! Я попробую эти варианты!
ИМХО, как-то у Вас все хардкорно. Маленькая библиотека — прям фрэймворк, который указывает на необходимый дизайн приложения и вносит зависимости (интерфейсы). При это все, что требуется для тестового набора — получить базу.
Так как данный подход очень мало распространен в .NET — почти нет никаких готовых библиотек для его реализации.
Подход распространен, нет смысла создавать библиотеку вокруг System.Data.SqlLocalDb. Пример, https://github.com/damianh/SqlStreamStore/blob/master/src/SqlStreamStore.MsSql.Tests/MsSqlStreamStoreFixture.cs
А для простых вставок данных (если абстрагироваться от логики самого приложения), достаточно и dapper-dot-net как легковесного решения (как пример подхода с минимумом абстракций).
У нас обычный тест выглядит так:
- получить базу (connection string)
- накатить схему
- добавить тестовые данные
- выполнить сам тест
- очистить ресурсы
Для ускорения, пустая база со схемой создается во время компиляции (post-build). А после, в каждом тесте/наборе, файл копируется и присоединяется (простой скрипт на master: CREATE DATABASE [...] ON (filename = ...)[, (filename = ...)]).
За наполнение данными отвечает сам тестируемый модуль, т.к. не всегда БД это только лишь CRUD, иногда есть поток сообщений/событий, из которого создаются проекции. Заодно и последнее тестируется.
Что касается "медленно" — так тут уже решается в рамках проекта, что и как тестировать. Как подсказали, иногда снэпшоты помагают. А иногда и разделение кода по репозиториям, как и сама оптимизация работы продукта.
Обычным подходом в .NET к тестированию приложений работающих с базой данных является внедрение зависимостей (Dependency Injection). Предлагается отделить код работающий с базой, от основной логики путем создания абстракции, которую в дальнейшем можно подменить в тестах.
То, о чем вы говорите — это не внедрение зависимостей, а инверсия зависимостей. И подменяется, если уж на то пошло, не абстракция, а ее реализации.
Все верно, посыпаю голову пеплом… Исправлю в статье.
Это очень мощный и гибкий подход, который тем не менее имеет некоторые недостатки — увеличение сложности, разделение логики, взрывной рост количества типов.
Логика в данном случае никак не разделяется — она как лежала в условном классе репозитория, так и лежит. Взрывного роста количества типов тоже никакого нет — добавляется всего-лишь по одному интерфейсу/абстрактному классу на каждый репозиторий. Отсюда резонный вывод, что сложность если и растет, то крайне незначительно, и увеличение косвенности в данном случае отбивается многократно уменьшением связанности модулей.
Ну вот есть у вас сложный запрос — он уходит в репозиторий, его теперь не видно из кода бизнес-логики… а в нем почти вся суть метода. А его ведь еще и протестировать нужно. И для чего мне тогда разделять их?
F12 это тоже проблема конечно, но меня больше смущает, что результат выполнения этого метода никому кроме моего бизнес-кода в этом конкретном методе и не нужен — зачем его выделять в отдельную сущность.
Ну вот есть у вас сложный запрос — он уходит в репозиторий, его теперь не видно из кода бизнес-логики… а в нем почти вся суть метода.
Если у вас суть метода бизнес-логики в сложном запросе, который вы перенесли в репозиторий, то у вас теперь бизнес-логика в репозитории. Который надо (теперь) тестировать теми же средствами, которыми тестируется остальная бизнес-логика.
И каким же?
"Такими же". Если у вас бизнес-логика тестировалась юнит-тестами — значит, и это место надо покрывать юнит-тестами. Если у вас бизнес-логика тестировалась интеграционными тестами — значит, надо покрывать интеграционным. Если вперемешку — то, понятное дело, никто вам не указ.
(впрочем, в большей части случаев и так никто не указ, чего уж...)
Ну вот приехали… то есть бывают случаи когда проще применить интеграционный тест?
Бывают.
Вы умеете тестировать sql-запросы модульными тестами?
Есть более простой подход, широко распространенный в мире динамических языков. Вместо создания абстракции, которую можно контролировать в тестах, этот подход предлагает контролировать саму базу.
Модульное и интеграционное тестирование — это два принципиально разных подхода. Сравнивать их подобно сравнению теплого и мягкого. Первый служит, вообще говоря, для спецификации интерфейсов и облечения рефакторинга, второй же — непосредственно для поиска дефектов. Чего вы хотите добиться, заменяя одно другим, остается непонятным еще с прошлой статьи.
То, что за пределами нашего привычного опыта тестируют по другому. И это работает и довольно неплохо.
Оно работает не в том смысле, что тесты загораются зеленым и красным. А в том, что достигается тот же и даже больший эффект меньшими усилиями.
Юнит тесты вообще нужны чтобы защитить код от шаловливых ручонок товарищей программистов. Если в проекте грамотные программисты, которые обсуждают с товарищами изменения (и до и после), то юнит тесты оказываются избыточными.
Ну вот лично я не считаю себя достаточно "грамотным" программистом, чтобы обойтись без юнит-тестов. А "обсуждение с товарищами" невозможно в силу размеров системы.
Ну вот лично я не считаю себя достаточно «грамотным» программистом, чтобы обойтись без юнит-тестов.
Я с вами соглашусь если из вашего утверждения убрать слово «юнит». Юнит-тесты — это просто один из способов тестировать код. Иногда удобный, а иногда не очень. Иногда оправданный, иногда не слишком. Меня беспокоит увлечение людей в индустрии именно этим типом тестов. Вера в исключительно полезные свойства именно юнит-тестов, ИМХО, иной раз достигает гипертрофированных масштабов, сродни чему-то религиозному.
А «обсуждение с товарищами» невозможно в силу размеров системы.
Под «товарищами», разумеется, понимаются те немногие, кто работал над конкретным модулем/куском кода. Найти оных и обсудить с ними вопрос обычно не представляет труда. Сколько у вас программистов окучивает один модуль или, скажем, фичер?
Я с вами соглашусь если из вашего утверждения убрать слово «юнит».
Я не очень понимаю, с чем тут соглашаться или нет, учитывая, что я говорю про себя.
Вера в исключительно полезные свойства именно юнит-тестов,
У юнит-тестов есть одно исключительное достоинство: скорость и простота запуска.
Под «товарищами», разумеется, понимаются те немногие, кто работал над конкретным модулем/куском кода. Найти оных и обсудить с ними вопрос обычно не представляет труда.
Особенно когда они уже не работают в компании, да.
Сколько у вас программистов окучивает один модуль или, скажем, фичер?
Если под "окучивает" вы понимаете "могут внести изменения", то больше десятка, я думаю.
У юнит-тестов есть одно исключительное достоинство: скорость и простота запуска.
Тесты нужны чтобы:
1. Проверить и отладить только что написанный код.
2. Убедиться что никто код не «испортил» ненамеренно.
Скорость и простота запуска важны только для 2 пункта. Во многих проектах этот пункт не так уж актуален.
"Рабочие данные есть у вас всегда" — это громкое заявление, конечно.
- На этапе разработки этих данных может тупо не быть в природе
- Данные могут быть настолько объёмные, что не помещаются в дев.окружение.
Так что рассматривать не всегда получается
А если у вас нету возможности сделать прикладной тест, то вы всегда будете производить кота в мешке. Все юнит тесты пройдут хоть тысячу раз, а реальный юз-кейс типа “ввёл стопку чеков, нажал кнопку, и получил годовой отчёт” всё равно может не пройти. А если ваша рабочая задача сделать экспорт из своего приложения в другое, и процесс экспорта подразумевает обработку данных? А если на выходе этих данных должно быть несколько гигабайт? С рандомно намоканной абракадаброй (а я такое видел) это не протестируешь, а внедрять всё это в определение какого-нибудь мега-монстро-теста кто угодно сойдёт с ума.
Для любых приложений нужны тестовые базы данных, будь то финансовая отчётность, учёт инвентаря, автоматизация рабочих процессов, машинное обучение, прогнозирование любой фигни от потребления птичьего корма до расхода топлива.
Так вот, фиктивные данные — они фиктивные, они не реальные. Это тоже мок, просто другого уровня.
Кейсы для случаев когда в БД оказались некорректные данные зачастую не тестируются вовсе.
Возможно их и стоило бы опускать при 100% покрытии. Вот только его в сложных случаях не бывает.
А именно там (в тех самых сложных случаях) тесты приносят наибольшую пользу.
Мой юз-кейз: Создание отчета по набору фильтров, заданному пользователем.
Существенная часть логики — конструирование сложного SQL-запроса по этому набору фильтров.
Я тестирую эту логику на настоящей (тестовой) базе — берем пустую схему, тестовый метод наполняет его набором данных, проверяем, что сконструированный запрос вернет ожидаемые данные.
Вопросы к знатокам:
- Это еще юнит-тест или уже интеграционный? (тут уточню, что создание и выполнение запроса это еще не все, что делает приложение при генерации отчета — там и пост-обработка, и слияние с данными из других источников).
- Можно ли (и имеет ли смысл) такой сценарий тестировать без БД? (речь идет о тестирование именно той части, которая делает первичную выборку данных на основе переданных фильтров)
- Это точно не юнит-тест. По большинству терминологий, юнит-тест — это тест без зависимостей и выполняющийся за очень короткое время
- Без БД это очень проблематично и не дает гарантии, что нет ошибок
Можно использовать для тестирования In-Memory DB. Юнит-тестами это будет если выполнение запроса, пост-обработка, слияние с другими источниками и генерация самого отчета будут проверяться раздельно.
Спасибо.
In-Memory DB
На другую БД заменить непросто, используются специфичные вещи типа JSON-функций в MySQL.
выполнение запроса, пост-обработка, слияние с другими источниками и генерация самого отчета будут проверяться раздельно
Да, я специально уточнил, что проверяется только логика построения запроса, который должен вернуть ожидаемые сырые данные (пост-обработка тестируется отдельно, уже без БД). Тогда это юнит-тест?
Тогда это что-то среднее. Модульный тест с элементами интеграционного.
Я думал про такой вариант (проверка sql-строки). Но он мне представляется непрактичным.
1) Sql не обязан быть детерминированным — допустим, порядок джойнов при подлитии второстепенных табличек меня не волнует. Пробелы и отступы опять же.
2) (более важно) Сам по себе sql получается сложным. И мне нужно будет теперь уже написать тесты на этот запрос — что такой-то запрос вернет такие-то данные. Точнее, на много разных вариантов запросов, которые может выдать мой генератор. Ибо моя конечная цель — не получение запроса, а выборка из базы.
моя конечная цель — не получение запроса, а выборка из базы.
Так как не существует абстрактной идеальной базы данных, для которой можно легко сделать моки (кроме, возможно, самых примитивных запросов), то остаётся делать только тесты на интеграцию с конкретной и настоящей базой данных.
Тестирование с базой данных в .NET