Hi Nat
You should not be testing Episerver APIs. Instead of hard wiring FilterAccess in your service, you should abstract the filter logic into another service class e.g. IMyFilterAccess, and make your service dependes on IMyFiterAccess interface, now you should be able to easily mock this.
Check out the repo below, you might find some useful stuffs to accelerate your unit tests.
Hi Vincent,
Thanks for the reply. I am definitely not trying to test EpiServer APIs, but I am finding that a lot of the Epi stuff is difficult to mock - it may simply be that the solution is simply not been coded with testing in mind.
I did take a look at FakeMaker, but couldnt get it to deal with Blocks - don't suppose there is a way to save blocks to the repo using FakeMaker?
Hi
I am trying to write some unit tests for our solution, and honestly I am finding it a bit like pulling teeth.
But I have managed to get as far as making/finding/altering a FakeContentRepository, such that I can CRUD pages and blocks.
however, I have a service that I am trying to write tests for, which gets pages from the repo, and then does the following:
I cannot see a way to change this up so that it is testable, certainly without changing up the code above.
Could anyone offer some suggestions please.
FilterAccess class seems to new up stuff in the ShouldFilter method, so I cant even inject any supporting Interfaces into the serviceLocator.
return new DefaultContentAccessEvaluator((IPublishedStateAssessor) new SimplifiedPublishedStateAssessor(args), (IPrincipalAccessor) new HttpPrincipalAccessor()).HasAccess(content, principal, requestedLevel)
thanks