Каковы преимущества самотестирования кода по сравнению с разделенными тестами?

Помещение их в том же протестированном классе может повредить популярные платформы поблочного тестирования, поскольку NUnit не протестирует типы, которые не имеют конструктора без параметров по умолчанию.

Помещение тестов в другом файле, но том же проекте лучше, но все еще вызывает Ваш основной проект сослаться на среды тестирования как NUnit.Framework.dll, а также любые платформы насмешки как Rhino.Mocks.dll.

Наличие Ваших тестов в классе под тестом также увеличивает размер Вашего распределенного проекта.

Выделите тесты в отдельный проект, и у Вас нет ни одной из этих проблем.

Сохранение Ваших тестов в отдельной области (подкаталог, проект, безотносительно) является хорошим способом сохранить опцию развернуть просто производственный код, который обычно является, что Вы захотите сделать.

Существует большое удобство в наличии Ваших тестов в том же классе, который Вы тестируете. Довольно часто (и до осуществления TDD), я использовал, добавляет Основной метод для класса только для тестирования функциональности кода, который я написал. И я не удалил основной метод, потому что было довольно полезно иметь тестовый код, лежащий вокруг. Это было удобно в том же смысле, что удобно связать документацию с Вашим кодом. Я еще не должен был смотреть, где или ищут тестовый код.

Однако точка TDD не является примерно тестированием/гарантией качества. Это больше о том, чтобы заставлять Вас думать о Вашем дизайне/интерфейсах. И от той точки наблюдения, имеет смысл иметь Ваш "тест" (иначе "дизайн") код в отдельном файле. Ваш "тестовый" код является клиентом/пользователем Вашего класса.

Если целью записать тесты в отдельном файле была техническая, т.е., "потому что платформа модульного теста была разработана тот путь" или "иначе необходимо будет включать ссылку в основной проект", или "это улучшает производительность", которая не звучит очень убедительной. Если бы это было вещами случая, был бы сделан очень по-другому.

Это - главным образом философское различие, я думаю.

Могут быть крайние преимущества производительности в наличии их в отдельном проекте (в так, поскольку Ваши тесты не развертываются в производство), но они, вероятно, не являются настолько значительными.

Также помните, что Рефакторинг был записан долгое время назад (в терминах IT), таким образом, предпочтенные методы, возможно, шли дальше с тех пор.

Я не вижу преимуществ в наличии тестового кода и производственного кода в том же классе. Вместо этого я вижу некоторые недостатки:

• Не будет возможно развернуть и распределить производственный код без тестового кода. Таким образом вместо файла 100 КБ Вы, возможно, должны были бы поставить 200 КБ или больший файл. (При использовании TDD там строки тестового кода часто равны или больше к строкам производственного кода.)

• Структура тестов слишком сильно связывается с производственным кодом. Должно быть отношение № 1:1 между тестами и производственными классами. Вместо этого должен быть 1:1 отношение между тестами и поведением.

Заключенный в кавычки из http://blog.daveastels.com.s3.amazonaws.com/files/BDD_Intro.pdf

"Когда Вы понимаете, что это - все об определении поведения и не записи тестов, Ваших сдвигов точки зрения. Внезапно идея наличия Тестового класса для каждого из Ваших производственных классов смехотворно ограничивает. И мысль о тестировании каждого из Ваших методов с его собственным методом тестирования (в отношениях 1-1) будет смехотворна".

Я программирую главным образом в Java, и я использую Знатока для разрабатывания моих проектов. Там у меня есть тесты в том же модуле и пакете как производственные классы, которыми они управляют на, но в другом каталоге (/src/main/java и/src/test/java). Когда Знаток разрабатывает проект, он выполняет все тесты, но только производственный код включен в распространяемый двоичный файл.

Приложение: 10 лет спустя (2019)

В наше время я являюсь главным образом рабочим в Clojure, и я иногда нахожу его удобным к тестам записи на функциональное право затем он в том же файле. Это только относится к чистым модульным тестам на небольшие вспомогательные методы. (Со статическим контролем типов некоторые из тех тестов могли бы быть ненужными.) Clojure позволяет исключить тесты из скомпилированной производственной сборки, так, чтобы избежал двоичного чрезмерного увеличения размера. И с тех пор clojure.test часть стандартной библиотеки, запись, что простые тесты в производственных файлах не требуют дополнительных зависимостей.

Тесты бизнес-логики, которые являются большинством всех тестов, я все еще, предпочитают сохранять в отдельном файле. Тем путем легче сфокусировать на чтении или производственный код или тестовый код - как система реализована по сравнению с тем, что это, как предполагается, делает - не будучи должен пропустить большие части чередованного кода. И интеграционные тесты всегда находятся в отдельном файле из-за тестовой помехи установки для установки базы данных и других зависимостей.

Существует также зеркальная сторона: Особенно при запуске на новом материале, я сначала реализую опцию в тестовом файле. Затем, когда структура начинает стабилизироваться, я извлекаю части ее для становления производственным кодом. Этот подход известен как TDD, как будто Вы Имели в виду Это. В коде kata я никогда не буду, вероятно, извлекать производственный код прежде, чем удалить проект, но в проекте работы он будет в конечном счете разделен к производству и тестовому коду.