Comments 9
Здорово видеть статью про Ignite!
Но ценность таких тестов, где всё замокано - сомнительна. В проде будет трансляция LINQ -> SQL. То, что работает в тесте, может не работать (или работать по-другому) с реальной базой.
Тем более, что запустить тестовый узел Ignite - одна строчка на C#. Это и проще, чем моки, и делает тесты гораздо более полезными.
Но ценность таких тестов, где всё замокано - сомнительна.
Потому это и модульный тест. Вы тестируте ваш модуль, а не сторонние библиотеки.
Спасибо за комментарий.
Unit тестирование - это проверка отдельных частей кода на корректность их работы. В данной статье я проверяю правильность работы фильтрации данных. А источник данных мне в данном тесте не важен, поэтому его мокаем. В статье я привел фильтрацию по одному параметру, но на практике их гораздо больше. Кроме того Apache Ignite не может фильтровать по DateTime, поэтому нужно переводить даты в long, и это тоже нужно проверять что все корректно.
Еще большой плюс юнит тестов, они помогают с архитектурой. Если какую то часть кода нельзя протестировать, значить в коде есть проблема.
Ну и не будем забывать про подход TDD, когда сначало пишется тест, а потом код. В решении сложных задач этот подход отлично работает.
Спасибо за интерес к статье.
В задачу Unit тестов не входит проверка работы реальных БД.
При тестировании кода с использованим EF в тестах используется контекст InMemory, который по сути тоже является моком, и при работе с реальной БД поведение может быть совсем другим.
Да, с EF InMemory те же проблема, лучше брать TestContainers и проверять запросы на реальной БД. Для Ignite всё проще, запускаем embedded node с in-memory cache.
В данной статье я проверяю правильность работы фильтрации данных
Не проверяете, т.к. с таким моком фильтрация работает совсем иначе, чем будет в проде.
Если какую то часть кода нельзя протестировать, значить в коде есть проблема.
Не всегда. Обратная сторона медали - Test-induced design damage
Здесь мы говорим про юнит тесты, поэтому нам не нужно развертывать реальные внешние системы. Такие тесты должны быть легкими и легковестными, эти тесты так же могут запускаться например при PullRequest в TFS.
Не проверяете, т.к. с таким моком фильтрация работает совсем иначе, чем будет в проде.
Да возможно какие то специфические фильтрации работают по другому с тем же Ignite, например DateTime, в тесте у нас он пройдет на ура, а при реальном Ignite будет ошибка. Но в общем случае этот тест закроет наши потребности.
По сути база. Если есть класс со статическими методами, то просто делаем обёртку с интерфейсом за которой скрываем статический класс и мокаем интерфейс обёртки.
В Вашем же случае это выглядит ни как класс со статическим методом, а как экстеншен для интерфейса и часто такие экстеншены сделаны для упрощения работы с интерфейсом, то есть вызывают методы интерфейса. В итоге можно замокать тот метод интерфейса, который вызывает этот экстеншен и обойтись без лишней обёртки в коде.
C#: использование Unit test с Apache Ignite