测试驱动开发的最佳实践使用C＃和RhinoMocks的 [英] Best Practices of Test Driven Development Using C# and RhinoMocks
问题描述
为了帮助我的团队编写可测试code，我想出的最佳做法，使我们的C＃code基更容易测试这个简单的列表。 （一些观点是指犀牛嘲笑，对于C＃嘲弄框架的限制，但这些规则可能适用更普遍为好。）有没有人有他们遵循的最佳做法？
要最大限度地提高code的可测性，遵循下列规则：
-
先编写测试，那么code 原因：这可确保您编写可测试code和code的每一行被测试写入吧。
-
使用依赖注入的设计类原因：你不能嘲笑或测试什么都看不出来
-
使用模型 - 视图 - 控制器或模型 - 视图 - presenter其行为的单独的用户界面code 原因：允许业务逻辑中，而部分测试不能进行测试（用户界面）被最小化。
-
不要写静态方法或类理由：静态方法是难以或不可能进行隔离和犀牛制品不能嘲笑他们
-
计划关闭接口，而不是类原因：使用接口澄清对象之间的关系。接口应该定义一个对象从它的环境需要的服务。另外，接口可以方便地使用犀牛制品和其他嘲弄的框架嘲笑。
-
隔离外部依赖理由：未解决外部依赖无法进行测试
-
标记为虚你打算方法来模拟原因：犀牛制品是无法模拟非虚方法
。
这绝对是一个好名单。这里有一些想法就可以了：
先编写测试，那么code。
我同意，在一个较高的水平。但是，我会更具体：编写一个测试，然后再编写的刚够的code通过测试，并重复。否则，我很害怕，我的单元测试将会看起来更像集成或接受测试。
使用依赖注入设计类。
同意。当一个对象创建其自己的依赖，你在他们身上没有控制权。控制/依赖注入的反转给你的控制，让您的对象，嘲笑/存根/等隔离测试。这是你如何在隔离测试对象。</ P>
使用模型 - 视图 - 控制器或模型 - 视图 - presenter其行为的单独的用户界面code。
同意。请注意，即使是presenter /控制器可以使用DI /国际奥委会通过其交给一个存根/嘲笑视图和模型测试。请查看 presenter首先 TDD更多这一点。
不写静态方法或类。
不知道我这一个认同。这是可能的单元测试，而无需使用嘲笑的静态方法/类。所以，也许这就是你提到的那些犀牛模拟特定规则之一。
计划关闭接口，而不是类。
我同意，但一个稍微不同的原因。接口提供的灵活性，软件开发者一个很大的 - 不仅仅是对各种模拟对象框架支持。例如，它是不可能正确地支持DI而不接口。
隔离外部依赖性。
同意。躲在一个接口自己的门面或适配器（如适用）的外部依赖。这将允许您将软件从外部依赖隔离，无论是web服务，队列，数据库或别的东西。这是的尤其的重要的，当你的球队不控制的依赖（也称为外部）。
标记为虚你打算方法来模拟。
这是犀牛制品的限制。在通过模仿对象框架prefers手codeD存根的环境中，这不会是必要的。
和，一对夫妇的新需要考虑的要点：
使用造物设计模式。这将有助于DI，但它也可以让你隔离code和单独测试它的其他逻辑。
使用 编写测试比尔唤醒的排列/法/断言技术。这个技术使得它非常清楚什么样的配置是必要的，什么是真正被测试，并期望是什么。
不要害怕推出自己的嘲弄/存根。通常情况下，你会发现，使用模拟对象的框架，使你的测试非常努力阅读。通过滚动你自己的，你必须在你的嘲笑/存根的完全控制，你就可以让您的测试可读。 （请参考前面的previous点。）
避免诱惑重构重复出你的单元测试到抽象基类，或安装/拆卸方法。这样做会隐藏配置/清理$ C $从显影剂c试图神交单元测试。在这种情况下，每个单独的测试的清晰度比重构出复制更为重要。
实施持续集成。查看 - 在你的code每一个绿色吧。构建软件和每个入住运行全套的单元测试。 （当然，这不是一种编码的做法，本身;但它是保持软件的清洁和完全集成的令人难以置信的工具）
In order to help my team write testable code, I came up with this simple list of best practices for making our C# code base more testable. (Some of the points refer to limitations of Rhino Mocks, a mocking framework for C#, but the rules may apply more generally as well.) Does anyone have any best practices that they follow?
To maximize the testability of code, follow these rules:
Write the test first, then the code. Reason: This ensures that you write testable code and that every line of code gets tests written for it.
Design classes using dependency injection. Reason: You cannot mock or test what cannot be seen.
Separate UI code from its behavior using Model-View-Controller or Model-View-Presenter. Reason: Allows the business logic to be tested while the parts that can't be tested (the UI) is minimized.
Do not write static methods or classes. Reason: Static methods are difficult or impossible to isolate and Rhino Mocks is unable to mock them.
Program off interfaces, not classes. Reason: Using interfaces clarifies the relationships between objects. An interface should define a service that an object needs from its environment. Also, interfaces can be easily mocked using Rhino Mocks and other mocking frameworks.
Isolate external dependencies. Reason: Unresolved external dependencies cannot be tested.
Mark as virtual the methods you intend to mock. Reason: Rhino Mocks is unable to mock non-virtual methods.
解决方案Definitely a good list. Here are a few thoughts on it:
Write the test first, then the code.
I agree, at a high level. But, I'd be more specific: "Write a test first, then write just enough code to pass the test, and repeat." Otherwise, I'd be afraid that my unit tests would look more like integration or acceptance tests.
Design classes using dependency injection.
Agreed. When an object creates its own dependencies, you have no control over them. Inversion of Control / Dependency Injection gives you that control, allowing you to isolate the object under test with mocks/stubs/etc. This is how you test objects in isolation.
Separate UI code from its behavior using Model-View-Controller or Model-View-Presenter.
Agreed. Note that even the presenter/controller can be tested using DI/IoC, by handing it a stubbed/mocked view and model. Check out Presenter First TDD for more on that.
Do not write static methods or classes.
Not sure I agree with this one. It is possible to unit test a static method/class without using mocks. So, perhaps this is one of those Rhino Mock specific rules you mentioned.
Program off interfaces, not classes.
I agree, but for a slightly different reason. Interfaces provide a great deal of flexibility to the software developer - beyond just support for various mock object frameworks. For example, it is not possible to support DI properly without interfaces.
Isolate external dependencies.
Agreed. Hide external dependencies behind your own facade or adapter (as appropriate) with an interface. This will allow you to isolate your software from the external dependency, be it a web service, a queue, a database or something else. This is especially important when your team doesn't control the dependency (a.k.a. external).
Mark as virtual the methods you intend to mock.
That's a limitation of Rhino Mocks. In an environment that prefers hand coded stubs over a mock object framework, that wouldn't be necessary.
And, a couple of new points to consider:
Use creational design patterns. This will assist with DI, but it also allows you to isolate that code and test it independently of other logic.
Write tests using Bill Wake's Arrange/Act/Assert technique. This technique makes it very clear what configuration is necessary, what is actually being tested, and what is expected.
Don't be afraid to roll your own mocks/stubs. Often, you'll find that using mock object frameworks makes your tests incredibly hard to read. By rolling your own, you'll have complete control over your mocks/stubs, and you'll be able to keep your tests readable. (Refer back to previous point.)
Avoid the temptation to refactor duplication out of your unit tests into abstract base classes, or setup/teardown methods. Doing so hides configuration/clean-up code from the developer trying to grok the unit test. In this case, the clarity of each individual test is more important than refactoring out duplication.
Implement Continuous Integration. Check-in your code on every "green bar." Build your software and run your full suite of unit tests on every check-in. (Sure, this isn't a coding practice, per se; but it is an incredible tool for keeping your software clean and fully integrated.)
这篇关于测试驱动开发的最佳实践使用C＃和RhinoMocks的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
