Поблочное тестирование и PostSharp
Я задаюсь вопросом, каково лучший способ сделать это... Я интересуюсь введением PostSharp в один из моих проектов, но я не уверен как классам модульного теста, отмеченным с атрибутом правильно.
Например:
public class hello {
[MyAspectThatDoesSomethingToTheDatabaseWhenThisMethodGetsCalled]
public int omg(string lol) {
//fancy logic in here
}
}
Я хотел бы протестировать логику в omg () метод, но в модульных тестах я должен удостовериться, что аспект не становится названным, потому что нет действительно базы данных.
Мысли?
4 ответа
Возможно, вы можете использовать инъекцию зависимостей и ввести статическое свойство для класса аспекта, где вы решаете, какой провайдер доступа к базе данных вы будете использовать (например, используя фабрику), устанавливая поддельный провайдер в области видимости теста.
Я считаю, что вам следует протестировать код, как если бы аспект был закодирован вручную - т.е. протестировать полную функциональность метода, включая функциональные возможности, реализованные аспектом.
Вопрос теперь задокументирован в онлайн-документации PostSharp по адресу http://doc.postsharp.net/postsharp-3.0/Content.aspx/PostSharp-3.0.chm/html/2ad6cf92-08eb-4537-a434- d88a3e493721.htm
Я не согласен с Gael. Я узнал от друга, что нужно тестировать код, который я собираюсь написать и вообще только один раз.
Я не совсем уверен, как работает postharp, но, как я сейчас понимаю, вы вызываете процесс пост-сборки, чтобы вплетать аспекты в IL.
Если я правильно понимаю, и если вы можете пропустить плетение после сборки, тогда вам следует тестировать свой метод, не зная аспекта (и тестировать аспект отдельно в другом месте).
Почему?
Если вы тестируете аспект и метод, вы тестируете сразу 3 вещи:
- метод
- аспект
- вплетение аспекта в код
Это является плохой кармой и может увести вас в кроличью нору, если что-то пойдет не так (а также превратить ваш модульный тест в интеграционный).
Глядя на список выше:
- вы действительно должны протестировать метод изолированно, без каких-либо других отвлекающих факторов, так как это позволит вам сосредоточиться на том, чтобы убедиться, что метод работает. именно то, что вы ожидаете - ни больше ни меньше.
- вам не нужно тестировать аспект каждый раз, он используется, просто протестируйте его один раз и убедитесь, что он делает то, что вы думаете
- вы не нужно проверять, работает ли ткачество ; он (должен быть) протестирован как часть пост-резкой реализации.