Почему testFixture вместо TestClass?

18

Существует три способа организации модульных тестов: Test for Fixture, Class или Feature. Но атрибут NUnit для TestClass называется TestFixture. Есть ли исторические причины для этого?

    
задан SiberianGuy 05.07.2010 в 06:55
источник

3 ответа

12

Основная историческая причина в том, что NUnit начал жизнь как прямой порт от JUnit, а junit назвал его тестовым креплением.

NUnit 1.0 был до моего времени, но мне сказали, что он начался, переименовав все .java-файлы в JUnit в .cs-файлы и пытаясь скомпилировать. Это было исправлено оттуда, и был добавлен пользовательский интерфейс. Когда я подключился к NUnit 2.0, в NUnit 1.0 по-прежнему был метод, называемый IsVisualAgeForJava , поскольку у JUnit было специальное поведение для этого в то время.

В NUnit 2.0 наша цель состояла в том, чтобы сделать NUnit более .NETish. Поэтому мы добавили атрибуты и кучу других вещей. Все мы пришли из java-фона и много лет работали с JUnit. Было вполне естественно использовать [TestFixture] .

    
ответ дан Mike Two 20.05.2011 в 16:15
источник
14

Я уважаю ответ Майка Два, но я бы сказал, что команда NUnit получила это очень не так, а использование [TestFixture] - это семантическая бородавка на лицевой стороне NUnit. Класс тестирования не является инструментом . Из того, что я вникнул в JUnit, я не нашел ссылки на тестовый класс в качестве тестового прибора, и я не нашел много дискуссий о «тестовых приспособлениях», относящихся к тестовым классам. Скорее всего, обсуждение JUnit / xUnit о светильниках относится к настройке и разрыву, что, конечно же, является распространенным методом, используемым для настройки реальных тестовых приборов.

Обратите внимание, что в NUnit 2.5 вы можете удалить аннотацию [TestFixture].

Обновление: (июль 2012 г.)

Я просто читал книгу огурцов и на странице 99, автор Мэтт Уинн объясняет происхождение использования «приспособления». Я цитирую:

  

Существует давняя традиция (исходящая из мира аппаратного обеспечения, в которой были созданы испытательные приборы) для вызова связи между тестовой системой и тестируемой системой. Это роль «кода клея», которую мы упоминали в этой книге как код автоматизации. В рамках этого теста термин FIT использует этот термин.    Некоторые инструменты тестирования модулей (например, NUnit) еще больше смутили проблему, обратившись к самому классу тестового примера как к устройству. Так много для вездесущего языка! (Wynne & amp; Hellesoy, 2012)

    
ответ дан ybakos 19.05.2012 в 17:33
источник
  • Я согласен с вами. Это была ошибка. Как только он там, его трудно вернуть. Однако я думаю, что в то время в JUnit было подобное поведение. Я мог быть совершенно неправ. Это было все в начале 2002 года, и я мог вспомнить об этом неправильно. В любом случае вы правы в своем утверждении, что тестовый класс и приспособление - это разные вещи. –  Mike Two 20.05.2012 в 12:48
  • Спасибо Майку Два, меня всегда очаровывают легендарные истории, стоящие за проектами нашего ремесла. Я также понимаю, что если мне это не нравится, я бы не скулил, но представил патч. Мне просто интересно, слишком ли я педантичен, так как никто другой не сделал этого изменения в NUnit на сегодняшний день. –  ybakos 20.05.2012 в 21:57
  • Я решил изменить его пару раз. Я ударил стену проблем с обратной совместимостью. Я прекратил регулярную работу NUnit несколько лет назад, поэтому я не намерен менять ее в будущем. –  Mike Two 20.05.2012 в 22:37
4

Теперь, когда вы спросите об этом, я просто посмотрел. Контрольное устройство - это фиксированное базовое состояние, которое должно быть установлено до начала испытаний, чтобы результаты были предсказуемыми и повторяемыми. В модульных системах тестирования мы используем атрибуты / методы SetUp и TearDown для создания / уничтожения тестового прибора (например, инициализация переменных экземпляра с помощью правильных объектов).

    
ответ дан Gishu 05.07.2010 в 07:07
источник