I am using Rhino.Mocks to mock objects for unit testing my .net application. I want to mock a static class. If someone has idea of how to do this, please suggest.
Short answer : you can't.
You can wrap the static up in a facade object and then mock that which will probably acheive wwhat you want.
See Mocking Static methods using Rhino.Mocks
Related
I am writing a unit tests using Xunit and moq. Within one function it calls Process.GetProcessesByName(). I need this to return a process with a certain pid which would exist when my program is actually running. However since in the test this process won't exist how do I mock away this call to return a fake process I want so I can continue to test the rest of the method?
You will need to wrap the call to Process.GetProcessesByName() in an injectable class in order to mock it. There is no way for Moq to replace behaviour of static methods.
There's a good answer on this topic here: How to mock static methods in c# using MOQ framework?
What you might be trying is a system testing/Integration testing. Trying to get actual value during unit testing is not what Unit testing is meant to do. The scope of unit testing is to validate the functionality of the piece of code not on the data. If you are interested in testing the actual data, try other testing methods like automation testing.
A method in the service which I'm unit testing is calling a static method that is present in another service.
I'm new to unit testing and have no idea how to mock these kinda dependencies. Please suggest!
There is already a thread here about this topic.
In fact it is not possible to create a service facade (Mock) for static methods.
My suggestion here is to refactor your code in that way that you make your class non static and create an interface for it. Than you can inject your dependency class in the normal system via IOC and in the unit test you can create a mock with frameworks like Moq or Rhinomocks.
I want to test a function with the type signature
public static void DoSomething<T>(T something)
where T : class, IInterfaceA, IInterfaceB, new()
which uses new T() internally.
I'm having problems creating a mock for T. Thanks to another question, I already found a solution for mocking multiple interfaces. However, I'm unable to create a mock satisfying the new() constraint. How do I solve this using Moq?
You have two options:
Use unconstraint mocking framework. In .NET it means either Isolator or JustMock. Both use IL weaving to inject code during runtime and can fake/mock object which are created inside the production code.
Split DoSomething logic and use dependency injection instead of creating the object as part of the logic.
Choosing between the two depends on how hard it is to split the logic, whether the remaining code has enough "meat" in it and if you're willing to pay for a Mocking framework that can fake new
I've got some code which downloads some RSS feeds.
I've been using WebClient or Argotic.Syndication.RssFeed libraries.
But these aren't mockable :(
I definately do not want to hit the real RSS feed every time I run the unit test.
Does anyone have any suggestions to what I can do?
Do I need to create an evil wrapper? If so .. suggestions on this?
Does anyone have any suggestions to what I can do?
Abstract the actual HTTP call behind an interface. Then write an implmentation of this interface using WebClient. Now have your main class take this interface as dependency. You could now mock this interface in the unit test and configure your dependency injection framework inject the correct implementation at runtime.
I go for creating a wrapper for every external dependency (if it's practical). So, every interaction with the filesystem/a webservice/database should be done through an interface only, which will lead to more testable code.
Another solution of course is (as always) Typemock Isolator.
Good evening,
I am working to get my head around unit testing and I'm having a little trouble determining how far I can push unit testing before it turns into integration testing.
An example from the project I'm working on now: it has a class that performs LDAP searches against Active Directory using DirectorySearcher and returns the results as Person objects. My first inclination was to grab the interface for DirectorySearcher and then create a fairly sophisticated stub that I can use for testing. However, that proved problematic because DirectorySearcher doesn't seem to use an interface and it would require a lot of code to stub it out successfully.
My next thought was to create an Searcher class that internally uses DirectorySearcher, which would let me test the mapping between the LDAP results and the Person object mapping, but that doesn't gain me very much and it's yet another level of abstraction.
So I guess the bottom line is this: is there a way structure this so I can do most of my work with unit testing? I'd really rather keep the integration test suite as small as possible, since I have to do the testing against an external data source that keeps changing. I suspect there's a pattern for doing this, but I haven't been able to find it.
Thanks!
If you have a class that you can't dependency inject, then the best pattern would be to create a wrapper object and wrap that object. Then, you can inject your wrapper (or mock of the wrapper) to gain that functionality.
So in your case, you were correct to create a wrapper "Searcher" class that internally calls DirectorySearcher. Whatever methods you need to call on the DirectorySearcher, you provide as virtual methods on your Searcher class. Then you can create a mock searcher class with overriden methods and inject that when unit testing (Or, have Moq create it for you!)
From what I can understand, your class (let's name it "PeoplePerson" for sake of discussion) needs to grab/reach people based on certain criteria. So its safe to say your class needs a PeopleRepository. We'll worry about how PeopleRepository is able to service calls like 'GetPeople(criteria)' later. Now if you test drive the development of PeoplePerson, you'd soon discover the right interface members (and they generally tend to be technology/impl. agnostic). Use a mocking framework (I'm assuming LDAP would make your unit tests slower) to inject a mock into PeoplePerson
public PeoplePerson(IPeopleRepository
repository) {... //cache it}
Now figure out how each method on the IPeopleRepository can be implemented. Write tests for PeopleRepository that work against a real ActiveServer/LDAP provider wrapping a known dataset. These tests will be slow (integration tests that test integration with the ActiveServer) but they free everyone else from worrying about LDAP/ActiveServer.
I find creating that abstraction a good investment.
You should create your own interface for the Searcher, than you'll wrap your Searcher object in a class that implement it, this way you'll be able to dependency inject your stub, or mock.