Модульное тестирование и PostSharp

Question

Мне интересно, как лучше всего это сделать ... Я заинтересован во внедрении PostSharp в один из моих проектов, но я не уверен, как правильно тестировать классы, помеченные атрибутом.

Например:

public class hello {

    [MyAspectThatDoesSomethingToTheDatabaseWhenThisMethodGetsCalled]
    public int omg(string lol) {
        //fancy logic in here
    }
}

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

Мысли

Answer 1

Я не совсем уверен, как работает postsharp, но, как я сейчас понимаю, вы вызываете процесс пост-сборки, чтобы интегрировать аспекты в IL.

Если мое понимание верно и если вы можете пропустить ткачество после сборки, то вам следует протестировать свой метод в неведении аспекта (и тестировать аспект отдельно где-то еще).

Почему?

Если вы тестируете аспект и метод, вы тестируете сразу 3 вещи:

1. метод
2. аспект
3. переплетение аспекта в коде

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

Глядя на список выше:

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

Answer 2

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

Вопрос теперь задокументирован в онлайн-документации PostSharp по адресу http://doc.postsharp.net/postsharp-3.0/Content.aspx/PostSharp-3.0.chm/html/2ad6cf92-08eb-4537-a434-d88a3e493721.htm

Answer 3

Если вы хотите написать чистый тест UNIT, рассмотрите возможность отключения PostSharp для модуля во время сборок UNIT TESTING, установив символ компиляции «SkipPostSharp» в своем проекте, или установите свойство MSBuild «SkipPostSharp = True».

Если вы счастливы провести интеграцию теста, вы можете проверить полную функциональность вашего метода и атрибута PostSharp, включая доступ к БД (как , предложенный Gael ).

Answer 4

Чтобы отключить аспекты, связанные с базой данных, в моем коде, я представил статический класс TestingEnvironment с логическим свойством TurnOffAspects. Код в аспекте проверяет это свойство, и если оно установлено в «true», аспект возвращается, ничего не делая. Во время настройки теста я установил для свойства TestingEnvironment.TurnOffAsprises значение true, а во время завершения теста - значение false. Конечно, вы можете сделать вещи более детализированными, вводя одно свойство для каждого имеющегося у вас аспекта. Вы должны очень тщательно выбирать, какие аспекты вы отключаете, поскольку это может оказать большое влияние на ваш тест и привести к сбою производственного кода даже при прохождении теста.

Answer 5

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

Answer 6

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

Я создал два разных определения сборки, в одном из которых аргументы MSBuild установлены на /p:SkipPostSharp=True (это тот, на котором выполняются юнит-тесты), а на другое - False соответственно. Кроме того, я установил для параметра Disable Tests значение True для определения сборки с использованием PostSharp.

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

Я также поиграл с Configuration Manager в Visual Studio, чтобы создать другое определение сборки, но все мои попытки вызвали больше проблем, чем что-либо еще.

Answer 7

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