Looking at the sample Account Plugin, it throws an exception when the account number is already set - so what testing that plugin’s throw exceptions under some conditions. This gives the Rhino logging output in the VS2010 test results most helpful during debugging asserts that don’t do as you expect. It’s worth noting the RhinoMocks.Logger assignment. In this case we are verifying that the Create method was called with the correct properties set on the task entity. The difference between a stub and a mock is that the mock records the calls that are made so that they can be verified after the test has been run. The key thing to notice is that the only mock object here is the OrganisationService - all others are stubs. S.Attributes.ToString() = "Send e-mail to the new customer." ((EntityReference)s.Attributes).Id.ToString() = entityId.ToString() OrganizationService.AssertWasCalled(x => x.Create(Arg.Matches(s => OrganizationService.AssertWasCalled(x => x.Create(Arg.Is.NotNull)) OrganizationServiceFactory.Stub(x => x.CreateOrganizationService(Guid.Empty)).Return(organizationService) įollowupPlugin plugin = new FollowupPlugin() Var organizationService = MockRepository.GenerateMock() ServiceProvider.Stub(x => x.GetService(typeof())).Return(organizationServiceFactory) Var organizationServiceFactory = MockRepository.GenerateStub() PipelineContext.Stub(x => x.OutputParameters).Return(outputParameters) ParameterCollection outputParameters = new ParameterCollection() PipelineContext.Stub(x => x.InputParameters).Return(inputParameters) InputParameters.Add("Target", new Entity("account")) ParameterCollection inputParameters = new ParameterCollection() ServiceProvider.Stub(x => x.GetService(typeof())).Return(pipelineContext) Var pipelineContext = MockRepository.GenerateStub() Var serviceProvider = MockRepository.GenerateStub() RhinoMocks.Logger = new TextWriterExpectationLogger(Console.Out) Public void FollowupPlugin_CheckFollowupCreated() Using Rhino Mocks allows us to create a mock Organisation Service and assert that the Create method was called passing a task with the desired attributes set. So by mocking the pipeline context, we can specify the account id, and check that the resulting task that is created is regarding the same account. So in our example, the Followup Plugin should create a task with the regarding id set to the id of the account. We can then say we are ‘Done’ when all tests pass.
This approach supports Test Driven Development (TDD), where the test is written first and then the desired functionality is added in order that the test passes.
#RHINO MOCKS CODE#
By mocking we are fixing behaviour and return values of the dependant code so that we can assert if the results are what we expect. The key principle of mocking is that we can exercise and examine the code that we need to test without executing the bits that are not being tested. To build the examples, you’ll need the CRM2011 SDK example plugins and Rhino Mocks 3.6 ( ).
#RHINO MOCKS HOW TO#
It’s been a while since Dynamics CRM 2011 Beta 1 was released (surely we are due Beta 2 soon!) so I thought it was about time I set up a Unit Test framework for PlugIns.
Next Post Unit Testing Dynamics CRM 2011 Pipeline Plugins using Rhino Mocks
0 kommentar(er)
