单元测试和 PostSharp
我想知道执行此操作的最佳方法是什么...我有兴趣将 PostSharp 引入到我的一个项目中，但我不确定如何对用属性正确标记的类进行单元测试。
例如：
public class hello {
[MyAspectThatDoesSomethingToTheDatabaseWhenThisMethodGetsCalled]
public int omg(string lol) {
//fancy logic in here
}
}
我想测试 omg() 方法中的逻辑，但在单元测试中我需要确保该方面不会被调用，因为实际上没有数据库。
想法？
I'm wondering what the best way to do this is... I'm interested in introducing PostSharp into one of my projects, but I'm not sure how to unit test classes marked with an attribute properly.
For example:
public class hello {
[MyAspectThatDoesSomethingToTheDatabaseWhenThisMethodGetsCalled]
public int omg(string lol) {
//fancy logic in here
}
}
I'd like to test the logic in the omg() method, but in the unit tests I need to make sure that the aspect doesn't get called, because there isn't really a database.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我不完全确定 postsharp 是如何工作的，但据我目前的理解，您调用构建后过程将各个方面编织到 IL 中。
如果我的理解是正确的，并且如果您可以跳过构建后编织，那么您应该在不了解方面的情况下测试您的方法（并在其他地方单独测试方面）。
为什么？
如果您测试方面和方法，那么您将同时测试 3 件事：
这是不好的因果报应，如果出现问题，可能会导致您陷入兔子洞（以及将单元测试转化为集成测试）。
查看上面的列表：
I'm not entirely sure how postsharp works, but as I currently understand, you invoke a post build process to weave the aspects into the IL.
If my understanding is correct and if you can skip the post-build weaving then you should be testing your method in ignorance of the aspect ( and testing the aspect separately somewhere else ).
Why?
If you test the aspect and the method, you are testing 3 things at once:
This is bad karma and may lead you down the rabbit hole if something goes wrong ( as well as making your unit test into an integration test ).
Looking at the list above:
我的观点是，您应该像手动编码方面一样测试代码——即测试方法的完整功能，包括方面实现的功能。
该问题现已记录在 PostSharp 在线文档中，网址为 http://doc.postsharp.net/postsharp-3.0/Content.aspx/PostSharp-3.0.chm/html/2ad6cf92-08eb-4537-a434-d88a3e493721.htm
My opinion is that you should test the code as if the aspect were coded manually -- i.e. test the full functionality of the method, including the functionalities implemented by the aspect.
The question is now documented in PostSharp online documentation at http://doc.postsharp.net/postsharp-3.0/Content.aspx/PostSharp-3.0.chm/html/2ad6cf92-08eb-4537-a434-d88a3e493721.htm
如果要编写纯 UNIT 测试，请考虑在 UNIT TESTING 构建期间通过在项目中设置编译符号“SkipPostSharp”来禁用模块的 PostSharp，或设置 MSBuild 属性“SkipPostSharp=True”。
如果您愿意进行集成测试，您可以测试方法和 PostSharp 属性的完整功能，包括数据库访问（如 由盖尔建议）。
If you want to write pure UNIT test, consider disabling PostSharp for the module during UNIT TESTING builds by setting the compilation symbol 'SkipPostSharp' in your project, or set the MSBuild property 'SkipPostSharp=True'.
If you are happy to do integration test, you can test full functionality of your method and PostSharp attribute, including DB access (as suggested by Gael).
我不同意盖尔的观点。
我从一位朋友那里了解到，我必须测试我要编写的代码，而且一般只测试一次。
I don't agree with Gael.
I've learned from a friend that I must test the code that I'm going to write and in general only once.
为了在代码中关闭与数据库相关的方面，我引入了一个名为 TestEnvironment 的静态类，其中包含一个名为 TurnOffAspects 的布尔属性。方面中的代码检查此属性，如果将其设置为“true”，则方面返回而不执行任何操作。
在测试设置期间，我将TestingEnvironment.TurnOffAspects 属性设置为true，并在测试拆卸期间设置回false。
当然，您可以使事情变得更细化，为您拥有的每个方面引入一个属性。您应该非常仔细地选择关闭哪些方面，因为它会对您的测试产生很大影响，并且即使测试通过，也会使您的生产代码失败。
In order to turn off aspects related to database in my code, I introduced a static class called TestingEnvironment with a boolean property called TurnOffAspects. The code in aspect checks this property and if it is set to "true", the aspect returns without doing anything.
During test setup I set TestingEnvironment.TurnOffAspects property to true, and during test teardown, back to false.
Of course you can make things more granular introducing one property per each aspect you have. You should choose very carefully what aspects you turn off, since it can have a great impact on your test and make your production code fail even when test passes.
也许您可以使用依赖项注入并为方面类引入一个静态属性，您可以在其中决定将使用哪种数据库访问提供程序（例如使用工厂），并在测试范围内设置假数据库访问提供程序。
Probably you can use dependency injection and introduce a static property for the aspect class where you decide which kind of database access provider you will use (e.g. using a factory), setting up the fake one in scope of a test.
我当前的方法是让测试作为 TFS 上构建过程的一部分运行。这可能不适用于所有场景，但我花了相当长的时间来找到一个解决方案，该解决方案允许我运行业务逻辑的单元测试，而不会受到 PostSharp 的任何影响。
我创建了两个不同的构建定义，其中一个将 MSBuild Arguments 设置为
/p:SkipPostSharp=True（这是运行单元测试的定义），另一个设置为False 分别。另外，我使用 PostSharp 将构建定义的Disable Tests选项设置为True。我知道这并不理想（特别是因为现在我遇到了无法在不进行任何更改的情况下在本地运行测试的问题），但我找不到任何其他解决方法。看来有同样问题的人并不多。由于我在 MSBuild 及其配置方面绝对是新手，因此也许具有更好知识的人可以提供帮助。
我还使用 Visual Studio 中的配置管理器来创建另一个构建定义，但我所有的尝试都只产生了比其他任何问题都多的问题。
My current approach is to have the tests running as part of the build process on our TFS. This might not be helpful for all scenarios, but I've spent quite a while to find a solution that would allow me to run the unit tests of our business logic without any impacts of PostSharp.
I created two different build definitions, one of which has the MSBuild Arguments set to
/p:SkipPostSharp=True(this is the one running the unit tests) and the other one toFalserespectively. Additionalliy, I set theDisable Testsoption toTruefor the build definition using PostSharp.I know this isn't ideal (especially because now I've got the problem of not being able to run the tests locally without any changes), but I couldn't find any other way around it. It seems that there aren't too many people with the same problems. As I'm an absolute newbie in terms of MSBuild and its configuration, maybe someone with a better knowledge could help.
I also played around with the
Configuration Managerin Visual Studio to create another build definition, but all my attempts only produced more problems than anything else.