Unit Testing and PostSharp

Question

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

Например:

public class hello { 

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

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

Мысли?

Answer 1

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

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

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

Answer 4

Я не совсем уверен, как работает postharp, но, как я понимаю, вы ссылаетесь на процесс создания сообщений, чтобы сплести аспекты в IL.

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

Почему?

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

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

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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