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