Когда я использую атрибут TestFixtureSetUp вместо конструктора по умолчанию?
5 ответов
Я думаю, что это было одной из проблем, которой не была решена nUnit командой. Однако существует превосходное xUnit проект , который видел эту точную проблему и решил, что конструкторы были хорошей вещью использовать на тестовая инициализация приспособления .
Для nunit, моя лучшая практика в этом случае должна была использовать TestFixtureSetUp, TestFixtureTearDown, SetUp, и TearDown методы, как описано в документации.
я думаю, что также помогает мне, когда я не думаю о тестовом приспособлении nUnit как о нормальном классе, даже при том, что Вы определяете его с той конструкцией. Я думаю о них как о приспособлениях, и это получает меня по умственному препятствию и позволяет мне пропускать эту проблему.
Почему необходимо было бы использовать конструктора в тестовых классах?
я использую [SetUp] и [TearDown] отмеченные методы для кода, который будет выполняться прежде и после каждого теста, и так же [TestFixtureSetUp] и [TestFixtureTearDown] отмеченные методы для кода, который будет выполняться только однажды и после того, как весь тест в приспособлении был запущен.
я предполагаю, что Вы могли, вероятно, занять место [TestFixtureSetUp] конструктора (хотя я не попробовал), но это только, кажется, повреждается из четкого соглашения, которое предоставляют отмеченные методы.
Я часто задавался вопросом, зачем нужен [TestFixtureSetUp] , учитывая, что существует простая, хорошо понятная конструкция языка первого класса, которая делает то же самое вещь.
Я предпочитаю использовать конструкторы, чтобы воспользоваться ключевым словом readonly, гарантирующим, что переменные-члены не могут быть повторно инициализированы.
Думаю, у меня есть хороший отрицательный ответ - причина использования конструктора вместо атрибута - это когда у вас есть наследование между тестовыми классами.
Только один метод, помеченный [TestFixtureSetup] будет вызываться (только для конкретного класса), но другие инициализаторы фикстуры не будут. В этом случае я бы предпочел поместить инициализацию в конструктор, который имеет четко определенную семантику для наследования :)
Одна вещь, которую вы не можете сделать с [TestFixtureSetup], которую вы можете сделать в конструкторе, это получить параметры из [TestFixture] .
Если вы хотите параметризовать тестовую оснастку, вам придется использовать конструктор по крайней мере для некоторых настроек. До сих пор я использовал это только для интеграционных тестов, например. для тестирования уровня доступа к данным с несколькими поставщиками данных:
[TestFixture("System.Data.SqlClient",
"Server=(local)\\SQLEXPRESS;Initial Catalog=MyTestDatabase;Integrated Security=True;Pooling=False"))]
[TestFixture("System.Data.SQLite", "Data Source=MyTestDatabase.s3db")])]
internal class MyDataAccessLayerIntegrationTests
{
MyDataAccessLayerIntegrationTests(
string dataProvider,
string connectionString)
{
...
}
}