эти тесты по существу стали интеграционными тестами, потому что они теперь тестируют интеграцию этих 2 классов? Или это - просто модульный тест, который охватывает 2 класса?
я думаю Да и Да. Ваш модульный тест, который охватывает 2 класса, стал интеграционным тестом.
Вы могли избежать его путем тестирования класса Предложения с ложной реализацией - класс MockWord, который важен, когда те части системы являются достаточно большими, чтобы быть реализованными различными разработчиками. В этом случае Word является единицей, протестированной один, Предложение является единицей, протестированной со справкой MockWord, и затем Предложение протестировано на интеграцию с Word.
Exaple реальной разницы может следовать 1) Массив 1 000 000 элементов является легко протестированной единицей и хорошо работает. 2) BubbleSort является легко единицей, протестированной на ложном массиве 10 элементов, и также хорошо работает 3), Интеграционное тестирование показывает, что что-то не прекрасно так.
, Если эти части разрабатываются единственным человеком, наиболее вероятная проблема будет найдена, в то время как поблочное тестирование BubbleSoft просто, потому что у разработчика уже есть действительный массив и он не должен дразнить реализацию.
Нет, к сожалению, это невозможно. См. Статические методы расширения.
Несколько людей предложили это: http://madprops.org/blog/static-extension-methods/
... но это никогда не было сделано в .NET 4. Очевидно, свойства расширения каким-то образом были созданы, но затем от них отказались.
https://blogs.msdn.com/ericlippert/archive/2009/10/05/why-no-extension-properties.aspx