Что-то не так с помещением методов тестирования в тот же класс, который вы тестируете?

Question

Что-то не так с помещением методов тестирования в тот же класс, что и класс, который вы тестируете?

Поэтому добавьте атрибут [TestFixture] к каждому классу и добавьте метод [Test] рядом с реальными методами.

Мне нравится идея.Хранит все в одном месте.

Но каковы, если таковые имеются, недостатки этого?

/ Я использую Nunit и c #.

Answer 1

Да, этого следует избегать. Тесты должны быть полностью отделены от кода доставки по крайней мере по следующим причинам

• Наличие тестов в отдельной сборке гарантирует, что у вас есть удобный API, так как они не могут использовать читы с помощью конструкций private / protected. Вместо этого они вынуждены проходить через публичные точки API
• Наличие тестов в одной сборке означает, что ваш производственный код также включает ваш тестовый код. Нет причин отправлять код клиенту, которого он на самом деле не будет использовать
• Заставляет производственный код принимать зависимости от сборок, которые им не нужны (Nunit, xunit и т. Д ...)
• Многие платформы тестирования требуют, чтобы методы тестирования были общедоступными, и поэтому тесты распространяются на открытую поверхность вашего API.
• Наличие их в одной сборке открывает дверь для производственного кода, случайно вызывающего тестовый код, и, следовательно, забавное утверждение появляется в производственной среде

Answer 2

Такой подход радует мою душу.

Я думаю, что гораздо разумнее отделить свой тестовый код от рабочего кода.Множество причин:

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

Больше всего:

Просто чувствует /пахнет неправильно.

Answer 3

Да.Это нарушит принцип единой ответственности.Это снизит читабельность.Вы добавляете зависимость в свою среду тестирования.

Answer 4

Самый большой недостаток: вы должны отправить свои тесты, и они потенциально могут стать частью вашего открытого API.

Answer 5

Вы не хотите использовать ярлыки.

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

Гораздо приятнее группировать тестовые классы в тестовых проектах. Это тогда не влияет на код, который тестируется, и намного легче следить за тем, какой код у вас есть.

Таким же образом вы не смешиваете пользовательский интерфейс и код бизнес-логики.

Так что, пожалуйста, пожалуйста, не смешивайте тесты с испытуемыми!

Answer 6

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

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

Answer 7

Downsides

Технически, у ваших классов будет больше методов, чем необходимо для использования в производственной среде. У вас также будут ссылки на nUnit, которые вам не нужны в производственной среде.

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

Answer 8

Чтобы добавить мои два цента:

Я согласен с большинством постов здесь, утверждая, что создание методов / функций тестирования с единственной целью тестирования является расточительным и потенциально, структурно дезорганизованным.

Однако, как правило, когда вы разрабатываете «с учетом тестирования», вы можете спроектировать свою реализацию так, чтобы она также тестировалась.Например, вы можете изначально разработать функцию / метод для использования переменной класса.Однако, если вы хотите проверить функциональность этого метода, вы можете спроектировать так, чтобы значение переменной класса «передавалось» в качестве параметра функции.

Теперь ваш метод является функциональным и тестируемым, т.е. функциональным тестированием.

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

Надеюсь, это поможет.Эта вики дает хороший обзор тестирования в программировании, в целом: http://en.wikipedia.org/wiki/Software_testing

Answer 9

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

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

Могут также быть аспекты, связанные с тем, почему не сделать это, как показано вмассив ответов уже затопляет - просто не делайте этого.

Answer 10

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

Если вы хотите, чтобы ваши тесты были в точности вместе с вашим классом, просто поместите их в один и тот жефайл:

public class Foo : IFoo
{
    ...
}

[TestFixture]
public class Foo_Tests
{
    ...
}