(转)Part 2 - Basic of mocking with Moq
2012-05-02 17:43
357 查看
See also: Â Part 1Â - Part 3
As every mocking framework, except TypeMock which can perform differently, every mocked class can't be sealed and methods that need to be mocked need to be public. If the class is not inheriting from an interface, the method that are being mocked need to be virtual.
Once this is cleared... let's show a simple example of a Product having it's price calculated with a Tax Calculator.
Here's what we are starting with:
?
The method we want to test here is Product.GetPriceWithTax(ITaxCalculator). At the same time, we don't want to instantiate a real tax calculator which gets it's data from a configuration or a database. Unit tests should never depend upon your application's configuration or a database. By "application's configuration", I mean "App.config" or "web.config" which are often changed during the life of an application and might inadvertently fail your tests.
So, we are going to simply mock our tax calculator like this:
?
Now It all depends on what you want to test. Depending if you are a "State" (Classic) or "Behaviour verification" (Mockist), you will want to test different things. If you don't know the difference, don't bother now but you might want to look at this article by Martin Fowler.
So if we want to make sure that "GetTax" from our interface was called:
?
If you want to make sure that the calculated price equal your product price with your tax added (which confirm that the taxes were calculated):
?
What's the difference? The first example verify the behaviour by making sure that "GetTax" was called. It doesn't care about the value returned. It could return 100$ and it would care. All that mattered in this example was that GetTax was called. Once this is done, we can assume that the expected behaviour was confirmed.
The second example is a state verification. We throw 25$ inside the tax calculator and we expect the tax calculator to return 5$ for a total price of 30$. It wouldn't call GetTax and it wouldn't care. As long as the proper value is returned, it's valid.
Some people will argue that behaviour is better than state (or vice versa). Personally, I'm a fan of both. A good example is that I might want to verify that an invalid invoice will not be persisted to the database and a behaviour verification approach is perfect for this case. But if I'm verifying (like in this case) that the tax were properly calculated, state behaviour is more often than not quicker and more easier to understand.
Nothing prevent your from doing both and making sure that everything works. I'm still not a full fledged TDD developer but I'm trying as much as possible to make tests for my classes as often as possible.
If you found this article helpful, please leave a comment! They will be mostly helpful for my presentation on February 25th 2009 at www.dotnetmontreal.com.
Currently rated 4.9 by 16 people
Reference URL: http://blog.decayingcode.com/post/part-2-basic-of-mocking-with-moq.aspx
As every mocking framework, except TypeMock which can perform differently, every mocked class can't be sealed and methods that need to be mocked need to be public. If the class is not inheriting from an interface, the method that are being mocked need to be virtual.
Once this is cleared... let's show a simple example of a Product having it's price calculated with a Tax Calculator.
Here's what we are starting with:
?
So, we are going to simply mock our tax calculator like this:
?
So if we want to make sure that "GetTax" from our interface was called:
?
?
The second example is a state verification. We throw 25$ inside the tax calculator and we expect the tax calculator to return 5$ for a total price of 30$. It wouldn't call GetTax and it wouldn't care. As long as the proper value is returned, it's valid.
Some people will argue that behaviour is better than state (or vice versa). Personally, I'm a fan of both. A good example is that I might want to verify that an invalid invoice will not be persisted to the database and a behaviour verification approach is perfect for this case. But if I'm verifying (like in this case) that the tax were properly calculated, state behaviour is more often than not quicker and more easier to understand.
Nothing prevent your from doing both and making sure that everything works. I'm still not a full fledged TDD developer but I'm trying as much as possible to make tests for my classes as often as possible.
If you found this article helpful, please leave a comment! They will be mostly helpful for my presentation on February 25th 2009 at www.dotnetmontreal.com.
Currently rated 4.9 by 16 people
Reference URL: http://blog.decayingcode.com/post/part-2-basic-of-mocking-with-moq.aspx
相关文章推荐
- Customization of SharePoint list menu item – Part 1 add Custom Action Item
- Understanding Blockchain Fundamentals, Part 2: Proof of Work & Proof of Stake
- Exploring the world of Android :: Part 2
- This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
- MMORPG大型游戏设计与开发(客户端架构 part6 of vegine)
- 错误:Component is part of the declaration of 2 modules
- How to Write a Masterpiece of a Resume - Part 1
- MySQL performance: Impact of memory allocators (Part 2)
- History of Monte Carlo Methods - Part 1
- LINQ Introduction Part 1 Of 3
- [i.mx6solo Dev] Part 1. Checklist of hardware
- A review of the Zend Framework - Part 1
- switch引发的错误 a label can only be part of a statement and a declaration is not a statement
- DL: Basic of C/C++(to be continued)
- LeetCode基本记录【4】// BASIC NOTES AND CODES OF LEETCODE [ 4 ]
- 【转】svn:is not under version control and is not part of the commit, yet its child解决办法
- Basic Elements of Oracle SQL 之 Pseudocolumns
- 48.The job t gather optimizer statistics for objects runs as part of the automatic maintenance windo
- c1 basic network concepts - The Layers of a Network
- Windows Store apps开发[19]C++/CX Part 0 of [n]: C++/CX简介