.Net mock framework

I have been using NUnit/MbUnit/VSTest to develop my tests for a while, but I don’t use mock frameworks too much. I have been reading some blog posts , but didn’t spend too much time digging into those frameworks too much. To effectively use those mock frameworks such as Rhino.Mocks and moq , you have to write your code in a TDD/BDD friendly way. Unfortunately, most of my projects are not designed this way, so I have to manually setup those stubs.

I started to look into the Asp.Net mvc framework lately and think it’s good opportunity to look into those frameworks because Asp.Net will definitely give those frameworks a push. If you download the Northwind example from here, you will find the example uses the moq framework.

Martin Fowler wrote a very good article on this topic.  I belong to the classic testers in his definitions.

Stephen Walther wrote a very good article here , and he provided a lot of background information regarding the Moq framework. His summary of the previous article is insightful.

In this paper, Fowler makes several distinctions. First, he distinguishes a stub from a mock. According to Fowler -- who uses Meszaros’ definitions here – stubs “provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.” Mocks, on the other hand, are “objects pre-programmed with expectations which form a specification of the calls they are expected to receive”.

This distinction between stubs and mocks leads Fowler to distinguish between state verification and behavior verification. Stubs are most often used when performing state verification. When performing state verification, you are interested in determining whether a certain condition is true or false at the end of a test. Mocks, on the other hand, are most often used when performing behavior verification. When performing behavior verification, you are interested in how the mock objects interact. For example, you want to know whether a not a certain method was called on one mock object after a method was called on another mock object.

Fowler makes a final distinction between classical TDD and mockist TDD. This final distinction concerns the “philosophy to the way testing and design play together”. A classical TDDer tends to use stubs and state verification. According to Fowler, the “classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing.” A mockist TDDer, on the other hand, almost always uses mocks and behavior verification. A mockist TDDer “will always use a mock for any object with interesting behavior.”

I find it very interesting to read the history of moq from its designer kzu, he created the framework initially because he is not satisfied with the other existing frameworks, however, he has to add a lot of other features into his framework such as VerifyAll. You can find a lot of interesting discussion from the evolving history of moq. Personally, I don’t see moq provides much more than Rhino Mocks. I probably reference both in my project.

Web Testing, Load Testing, Unit Testing...

I understand that unit testing should cover most of scenarios if an application is nicely designed with some pro-unit testing framework, namely MVC pattern. In .Net world, those unit testing friendly frameworks include Asp.Net MVC, and Castle Project. But a lot of times, an application has already been designed and put into the production, you don't have time, money, and energy to re-write those anti-unit testing applications based on unit-testing friendly framework.  Mostly importantly, business users don't understand why you want to rewrite an application just because you want to be able to unit testing it, they just need a workable application, and don't care too much about the back end unit testing which is an essential part of the whole project.

I am working on an application which is heavily depend on CSLA.Net framework, which is a very impressive framework. However, the framework is not very TDD friendly, and check out some discussions in this post. I started to look for some other alternatives which can automate the testing process, and the visual studio team system had an edition for software testers starting from Visual studio 2005. But honestly, I won't recommend using it unless you have the VS2008 version. The biggest limitation of VS2005 test version is that it doesn't support Ajax testing natively, and you have to rely on fiddler tool to record the testing. VS 2005 test version cannot detect dynamic parameter very well, and I have big trouble to get those viewstate related variables work. VS 2008 version definitely did a lot of improvements in those areas, although it's not free of bugs either. Check out an excellent post on web test in visual studio 2008 here.

A couple of roadblocks I have in working on the automating tests are:

1. You have to turn page validation off and view state check off. You probably want to turn it back in production environment.

<pages theme="Main" enableEventValidation="false" enableViewStateMac="false" >

2. You may need to hard code a machine key if you want to port the test to different sites. In our cases, we recorded the tests on a test website, but we also want to run it on stage site too.

   1: <machineKey

   2:     validationKey="9A1F64F585E06F97562808D96860AC9E3DA5F231EA34B42E8C98AE02B52EAF33CF7EF24C618F7F391756974090458C9740BE1007E6F898161C39B863A7E46C3D"

   3:     decryptionKey="376909E1031E5AA520AAE33B554ACACCE0CAEA2BA0B142FB3050D814059398CB"

   4:     validation="SHA1" decryption="AES"/>  

3. Some post parameters are promoted as dynamic parameters incorrectly, watch out those if you need manually correct those.

4. Check out this web test plug in if you want to use some .Net functions in your test.

Sometimes, you want to create set up some specific pre-testing condition, and tear down those values added to your database in your testing, you can create a plug in to do this work.

In our projects, in PreWebTest, we create an object in the database which we need run our test on, and in PostWebTest, we delete this object. It works very well for our situation. We run those tests every day , and those green pass icons definitely make our life much easier.