Интригующий! Я никогда раньше не видел, чтобы кто-нибудь применял анализ NDepend для тестирования проектов. Хотя модульные тесты следует считать первоклассными гражданами вашей кодовой базы, они, как правило, не развертываются вместе с приложением и поэтому не рассматриваются с одинаковыми архитектурными ограничениями (FxCop, NDepend и т. Д.). На некотором уровне я согласен с этим подходом, качество тестов должно быть проверено, но я не могу понять, какую пользу может принести инструмент здесь, кроме выявления проблем связывания классов, которые также будут определены в производственном коде.
Что касается NUnit, он обычно создает один экземпляр testfixture для всех методов тестирования в этом классе тестирования. Состояние является общим для тестов, и это хорошо и плохо.
Хорошо: состояние, для создания которого требуется время, может быть задано при настройке тестового прибора.
Плохо: состояние, которое следует сбросить между тестами, зависит от вас, чтобы исправить между тестами.
Если NUnit поддерживает статические методы для тестов и если вам нужно какое-либо состояние в тестовом устройстве, эти поля должны быть статическими. Это действительно очень страшно, потому что состояние ваших тестов распределяется на протяжении всего жизненного цикла тестового домена приложения.
Ключ должен использовать атрибуты NUnit для фиксации и инициализации / разрыва теста. Никогда не используйте конструкторы или финализаторы для инициализации фикстуры, поскольку вы не можете контролировать, когда среда NUnit создает ваш класс.