What is mock

A mock object is a fake object in the system that decides whether the unit test has passed or failed. It does so by verifying whether the object under test interacted as expected with the fake object.

Refactory to break dependency

• Extract an interface to allow replacing underlying implementation
• Inject stub implementation into a class under test
• Receiving an interface at the constructor level.

  If your code under test requires more than one stub to work correctly without dependencies, adding more and more constructors ( or more and more constructor parameters) becomes a hassle, and it can even make the code less readable and less maintainable. One possible solution is using inversion of control containers. You can think of IoC containers as "smart factories" for you objects. A container provide special factory methods that take in the type of object you'd like to create and any dependencies that it needs, and then initialize the object using special configurable rules such as what constructor to call, what properties to set in what order, and so on. They are powerful when put to use on a complicated composite object hierarchy where creating an object requires creating and initializing object serveral levles down the line. Using constructor arguments to initialize objects can make you testing code more cumbersome unless you're using helper frameworks such as IoC containers for object creation. Every tie you add another dependency to the class under test, you have to create a new constructor that takes all other arguments plus a new one, make sure it calls the other constructors correctly, and make sure other users of this class initialize with the new constructor.

  On the other hand, using parameters in constructors is a great way to signify to the user of your API that these parameters are non-optional. They have to be sent in when creating the object.

  If you want these dependencies to be optional, use properties, which is much more relexed way to define optional dependencies adding different constructors to the class for each dependency. If you choose to use constructor injection, you'll probably also want to use IoC containers. This would be a great solution if all code in the world were using IoC, containers. The future of unit testing will use more and more of these Ioc pattern.

• Receive an interface as a property get or set.

  Use this technique when you want to signify that a dependency of the class under test is optional, or if the dependency has a default instance created that doesn't create any problems during the test.

Cancel Hanlder

The cancel handler view provides a way to define activity cancellation logic. A cancel handler has some similarities to the fault handlers just discussed. Like fault handlers, they are attached only to a composite activity.However, cancel handlers don’t catch and handle exceptions. Instead, they specify the cleanup actions that take place when an executing activity is canceled.

actions that take place when an executing activity is canceled. The need for cancel handlers is best illustrated with an example: A ListenActivity is a composite activity that allows you to define multiple child activities under it. Assume that each child of the ListenActivity is a HandleExternalEventActivity that listens for a different external event. With this scenario, each HandleExternalEventActivity is executing at the same time waiting for an event. Only one of these children will eventually receive its event and complete execution. The other sibling activities will be canceled by the ListenActivity parent. By entering a cancel handler for the parent ListenActivity, you define the steps to execute when the incomplete children are canceled. You won’t always need a cancel handler. But if your activities require any cleanup when they are canceled, a cancel handler is an appropriate place to define that logic.

ActivityExecutionContext

1. It is a container of services that is availabe to activities ruing their execution. This set of service is the same for all activities in all WF program instances. Some services are provided by the WF runtime and are always obtainable from AEC. Custom services can be offered by the application that hosts the WF runtime; such services are made available to activities by using the AddService method of WorkflowRuntime.

   class ReadLine:Activity
   {
       private string text;
       public string Text
       {
           get { return text; }
       }
   
   

Test asp.net mvc route

//arrange
RouteCollection routes = new RouteCollection();
MvcApplication.RegisterRoutes(routes);
var httpContextMock = new Mock<HttpContextBase>();
httpContextMock.Expect(c => c.Request.AppRelativeCurrentExecutionFilePath).Return("~/product/list");