Единичное тестирование и PostSharp

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

Например:

public class hello {

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

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

Мысли?

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

Почему?

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

  • метод
  • аспект
  • плетение аспект в код

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

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