Да вы правы это расширение и мы можем замокать интерфейс. Но в данном случае не все так просто, это расширение имеет большую глубитну вложенных расширений, в которых к тому же присутствует дополнительный код. И поэтому я сделал обертку. Нам же нужно тестировать сам ignite.
Здесь мы говорим про юнит тесты, поэтому нам не нужно развертывать реальные внешние системы. Такие тесты должны быть легкими и легковестными, эти тесты так же могут запускаться например при PullRequest в TFS.
Не проверяете, т.к. с таким моком фильтрация работает совсем иначе, чем будет в проде.
Да возможно какие то специфические фильтрации работают по другому с тем же Ignite, например DateTime, в тесте у нас он пройдет на ура, а при реальном Ignite будет ошибка. Но в общем случае этот тест закроет наши потребности.
В задачу Unit тестов не входит проверка работы реальных БД.
При тестировании кода с использованим EF в тестах используется контекст InMemory, который по сути тоже является моком, и при работе с реальной БД поведение может быть совсем другим.
Unit тестирование - это проверка отдельных частей кода на корректность их работы. В данной статье я проверяю правильность работы фильтрации данных. А источник данных мне в данном тесте не важен, поэтому его мокаем. В статье я привел фильтрацию по одному параметру, но на практике их гораздо больше. Кроме того Apache Ignite не может фильтровать по DateTime, поэтому нужно переводить даты в long, и это тоже нужно проверять что все корректно.
Еще большой плюс юнит тестов, они помогают с архитектурой. Если какую то часть кода нельзя протестировать, значить в коде есть проблема.
Ну и не будем забывать про подход TDD, когда сначало пишется тест, а потом код. В решении сложных задач этот подход отлично работает.
Спасибо за комментарий.
Да вы правы это расширение и мы можем замокать интерфейс. Но в данном случае не все так просто, это расширение имеет большую глубитну вложенных расширений, в которых к тому же присутствует дополнительный код. И поэтому я сделал обертку. Нам же нужно тестировать сам ignite.
Здесь мы говорим про юнит тесты, поэтому нам не нужно развертывать реальные внешние системы. Такие тесты должны быть легкими и легковестными, эти тесты так же могут запускаться например при PullRequest в TFS.
Да возможно какие то специфические фильтрации работают по другому с тем же Ignite, например DateTime, в тесте у нас он пройдет на ура, а при реальном Ignite будет ошибка. Но в общем случае этот тест закроет наши потребности.
Спасибо за интерес к статье.
В задачу Unit тестов не входит проверка работы реальных БД.
При тестировании кода с использованим EF в тестах используется контекст InMemory, который по сути тоже является моком, и при работе с реальной БД поведение может быть совсем другим.
Спасибо за комментарий.
Unit тестирование - это проверка отдельных частей кода на корректность их работы. В данной статье я проверяю правильность работы фильтрации данных. А источник данных мне в данном тесте не важен, поэтому его мокаем. В статье я привел фильтрацию по одному параметру, но на практике их гораздо больше. Кроме того Apache Ignite не может фильтровать по DateTime, поэтому нужно переводить даты в long, и это тоже нужно проверять что все корректно.
Еще большой плюс юнит тестов, они помогают с архитектурой. Если какую то часть кода нельзя протестировать, значить в коде есть проблема.
Ну и не будем забывать про подход TDD, когда сначало пишется тест, а потом код. В решении сложных задач этот подход отлично работает.