I'm working on an ASP.NET MVC 2 project. I've been handed a few controller classes with a tight dependency on a data repository class, something like this:
public class MyController : Controller
{
MyRepository myRepository = new MyRepository();
// ...
}
Class MyRepository is concrete, not an interface.
Basically, while I have read access to this code I don't have write access. I'm trying to write some unit tests to make sure it works. Needless to say I don't want to have the actual database get hit as I do this, so clearly some sort of mocking is in order.
I'm fairly new to unit testing and mocking, but I've read up on Moq and I think I get the basic idea of how it works. I've been able to successfully create a simple mock repository object... but the problem is, I still don't know how to pass it into the class!
If I'd written the original code I would have used an interface rather than a concrete class, and I would have written an extra constructor for dependency injection. As it is, I'm in a mess.
Can Moq help me pass it into the class (if I mock MyController), or do I need to petition for write access so I can refactor?
I would recommend you to ask write access and change the code to use constructor injection. Everything else would be hacks which won't bring much value to this code. As long as a class has strong coupling with some other class it is close to impossible to unit test and even if you find some method this test will be so brittle that it would be a waste of time.
You are correct in that to do this properly you need to have a public way of injection your own mock of the repository. Moq will not help you here. You should try to change the MyController code to enable this kind of dependecny injection.
If you cannot chagne the code, you could always change things using private reflection. But doing this fragile because a change in the controllers implementation can break your tests.
Of course, then you need to figure out how to mock the repository. If it was not designed for mocking then something like Moles could work
Related
since i do not get my head around the unit tests.
I have a service
public interface IMyService
{
public List<Person> GetRandomPeople();
}
And then in my MVC Project I have the implementation of this service
public MyService : IMyService
{
public List<Person> GetRandomPeople();
{
...the actual logic the get the People here. This is what i want to test ?
}
}
Then in my controller
public HomeController : Controller
{
IMyService _myService;
public HomeController(IMyService myService)
{
_myService = myService
}
}
Then in the Action Method I will use
public ActionResult CreateRandom()
{
List<Person> people = _myService.GetRandomPeople();
return View(people)
}
Note : The person repo is in my service, just typed this out quickly, so i have a repo.
My Question : How would i test my Service implementation in my Tests projects. I am really stuck now, and i think this is going to the "light goes on" moment in my TDD future.
thanks in advance.
The point of injecting the service interface into the controller is to allow you to test the controller in isolation. To test that, you pass in a mock or fake IMyService.
Depending on how your service is implemented, you may need to test your service with integration tests. Those should be separate from your unit tests (as you don't want to run them continuously).
For example, let's say IMyService is implemented with Entity Framework. You need to actually run the LINQ to Entities against a database to test it. You could use a local database, you could have EF create and populate a database on the fly, etc. Those aren't unit tests (they use I/O), but they're still important.
Other persistence frameworks may permit you to test against in-memory data sets. That's fine; I'd still consider that an integration test (your code + the framework) and would separate it from your unit tests.
The trick is to keep the business logic out of the service implementation. Restrict that (as much as possible) to pure data-access code. You want to test your business logic with unit tests.
EDIT:
To address the question in the comment ("when you need to create stubs"):
You create stubs, fakes, test doubles, or mocks (there's a lot of terminology) when you have a class that you want to test in isolation (the system under test, or SUT) and that class has injected dependencies.
Those dependencies are going to be abstract in some way - interfaces, abstract classes, classes with virtual methods, delegates, etc.
Your production code will pass concrete implementations in (classes that hit the database, for instance). Your test code will pass test implementations in.
You could pass a simple stub implementation (just write a dummy class in your test project that implements the interface and returns fixed values for its members), or you could have a fancier implementation that will detect what calls are made and what arguments are passed (a mock object). You can write all of this by hand. It gets tedious, so many testers use mock object frameworks (also known as isolation frameworks). There are many of these (often several for any given language); I tend to use either NSubstitute or Moq in .NET.
Learning to write tests takes time. It helped me a lot to read several books on the subject. Blog posts may not give enough background. There are some excellent suggestions in the (sadly closed) question here.
The short answer is that you create stubs or mocks when your tests require them.
I'm having a simple test design problem, which I would like to solve once and for all.
I'm pretty used to regular Java design pattern where there is some Manager interface (or facade) and a set of DAO interfaces. Concrete implementation of ManagerImpl is using concrete implementations of DaoImpl.
Right now I'm at the point of implementation, where I don't have a database connected to my project yet, so I guess this is a perfect time to write proper unit tests without DB :-)
I was able to mock some methods of my manager by using mockito, but since the Test Under Method (or so called System Under Test) is using DAO internally, I would have to mock the DAO as well. Unfortunately I cannot do that without setting concrete DAO implementation in my manager, like myManager.setMyDao(mockedDao), but now I would have to pull out this setMyDao method into interface, which of course breaks encapsulation and makes my clean and perfect interfaces look like garbage.
So the question is: How to mock DAO in tests while preserving clean Manager-Dao architecture?
You should unit test concrete implementations, i.e. ManagerImplTest, which will explicitly create ManagerImpl and therefore you have all setMyDao methods available for mocks. Your test will not know about Manager interface.
BTW, it is not always necessary to create interfaces for everything. In most cases only single implementation of managers and daos will exist. If there is no any other strong reason (e.g. Spring AOP proxies or dependency separations), I guess it's better don't create interfaces for everything in sake of simplicity.
You can get rid of set methods altogether and inject factory. This way no extra method is exposed (in fact, no extra method even exists) and problem disappears. Then in test you configure factory mock to return DAO mocks and from that point on it's plain and simple.
First of all let me say I am working from legacy code. So some changes can be made but not drastic ones.
My problem is I have a "Vehicle" object, it is pretty simple but has no interfaces or anything on it. This project was created before TDD really started to become more main stream. Anyway, I need to add a new method to change the starting mileage of the vehicle. I thought this would be a good start to try TDD and Mocking as I am new it all. My problem is I need to create a vehicle do some checks which involve going to the database. Sorry if my question is not 100% clear, is why I am posting as I am a bit confused where Rhino Mocks fits in (and if I need it!).
The problem is dependencies. Your vehicle class depends on the database. Hopefully all the interactions with the database have been encapsulated into a nice class we will get back to that in a second. When you fire off your unit test you want to be able to test the vehicle class without having to care about the database. For example you want to check that your SpeedUp(int x) method really increases the total speed by x. In this method the first thing it does is it asks the DB for its current speed. That means that you have to have a DB to test! Dam, that doesn't sound like a very fast test nor repeatable. Also a lot of setup to just run a test.
Wouldn't it be great if we could have a pretend DB? That is where mocking comes in. We create a Mock of the class that has all the DB interaction encapsulated. We then setup the mock to respond with a prepgrammed value. So for example when we ask the DB for current speed you return 100.
So now when we test the mock returns a 100 and we can assert that SpeedUp(int x) takes 100 and adds x to it.
Rhino mocks can only create mocks from interfaces or abstract classes, which do not exist your legacy code.
TypeMock can mock anything but isn't free.
You could use Microsoft Moles to mock these out.
You should however take into account that Moles should be your last resort solution, it's better to refactor your code and make it testable by abstracting your datalayer from your business layer.
HTH
Is it easy to create an instance of the Vehicle type (an object) and then invoke your method for a test ? If yes, then chances are you don't need a mock.
However if your Vehicle type has dependencies (like a Database access object) that it needs to perform the action that you want to test, then you would like to use a mock database access object that returns canned values for the test since you want your unit tests to run fast.
Vehicle [depends On>] OwnerRepository [satisfied By] SQLOwnerRepository
So you introduce an interface (an OwnerRepository to get details of the owner, let's say) to separate the DB Interaction (define a contract) between the two. Make your real dependency (here SQLOwnerRepository) implement this interface. Also design your code such that dependencies can be injected e.g.
public Vehicle (OwnerRepository ownerRepository)
{ _ownerRepository = ownerRepository; // cache in member variable }
Now in the test code,
Vehicle [depends On >] OwnerRepository [satisifed By] MockOwnerRepository
You have frameworks that given an interface would create a mock implementation of it (See Rhino/Moq frameworks). So you no longer need an actual DB connection to test your Vehicle class. Mocks are used to abstract away time consuming / uncontrollable dependencies in order to keep your unit tests fast / predictable.
I'd recommend reading up on "Dependency Injection" to have a better understanding of when and why to use mocks.
Not a direct answer to your question. However it is worth to take a look at the following.
Gabriel Schenker has posted about applying TDD in legacy systems. PTOM – Brownfield development – Making your dependencies explicit
This article explains about making dependencies explicit and using Dependency Injection. It also tell s about Poor Man’s Dependency Injection. This is needed when there is only default constructor.
Something like
public OrderService() : this(
new OrderRepository(),
new EmailSender(ConfigurationManager.AppSettings["SMTPServer"])
)
The article also deals with creating a wrapper for ConfigurationManager for making it testable.
During a recent interview I was asked why one would want to create mock objects. My answer went something like, "Take a database--if you're writing test code, you may not want that test hooked up live to the production database where actual operations will be performed."
Judging by response, my answer clearly was not what the interviewer was looking for. What's a better answer?
I'd summarize like this:
Isolation - You can test only a method, independently on what it calls. Your test becomes a real unit test (most important IMHO)
Decrease test development time - it is usually faster to use a mock then to create a whole class just for help you test
It lets you test even when you don't have implemented all dependencies - You don't even need to create, for instance, your repository class, and you'll be able to test a class that would use this repository
Keeps you away from external resources - helps in the sense you don't need to access databases, or to call web services, or to read files, or to send emails, or to charge a credit card, and so on...
In an interview, I'd recommend including that mocking is even better when developers use dependency injection, once it allows you to have more control, and build tests more easily.
When unit testing, each test is designed to test a single object. However most objects in a system will have other objects that they interact with. Mock Objects are dummy implementations of these other objects, used to isolate the object under test.
The benefit of this is that any unit tests that fail generally isolate the problem to the object under test. In some cases the problem will be with the mock object, but those problems should be simpler to identify and fix.
It might be an idea to write some simple unit tests for the mock objects as well.
They are commonly used to create a mock data access layer so that unit tests can be run in isolation from the data store.
Other uses might be to mock the user interface when testing the controller object in the MVC pattern. This allows better automated testing of UI components that can somewhat simulate user interaction.
An example:
public interface IPersonDAO
{
Person FindById(int id);
int Count();
}
public class MockPersonDAO : IPersonDAO
{
// public so the set of people can be loaded by the unit test
public Dictionary<int, Person> _DataStore;
public MockPersonDAO()
{
_DataStore = new Dictionary<int, Person>();
}
public Person FindById(int id)
{
return _DataStore[id];
}
public int Count()
{
return _DataStore.Count;
}
}
Just to add on to the fine answers here, mock objects are used in top-down or bottom-up structural programming (OOP too). They are there to provide data to upper-level modules (GUI, logic processing) or to act as out mock output.
Consider top-down approach: you develop a GUI first, but a GUI ought to have data. So you create a mock database which just return a std::vector<> of data. You have defined the 'contract' of the relationship. Who cares what goes on inside the database object - as long as my GUI list get a std::vector<> I'm happy. This can go to provide mock user login information, whatever you need to get the GUI working.
Consider a bottom-up approach. You wrote a parser which reads in delimited text files. How do you know if it is working? You write a mock 'data-sink' for those object and route the data there to verify (though usually) that the data are read correctly. The module on the next level up may require 2 data sources, but you have only wrote one.
And while defining the mock objects, you have also define the contract of how the relationship. This is often used in test-driven programming. You write the test cases, use the mock objects to get it working, and often than not, the mock object's interface becomes the final interface (which is why at some point you may want to separate out the mock object's interface into pure abstract class).
Hope this helps
Mock objects/functions can also be useful when working in a team. If you're working on a part of the code base that depends on a different part of the code base that some else is responsible for - which is still being written or hasn't been written yet - a mock object/function is useful in giving you an expected output so that you can carry on with you're work without being held up waiting for the other person to finish their part.
Here are the a few situations where mocking is indispensable:
When you are testing GUI interaction
When you are testing Web App
When you are testing the code that interacts with hardware
When you are testing legacy apps
I will go a different direction here. Stubbing/Faking does all of the things mentioned above, but perhaps the interviewers were thinking of mocks as a fake object that causes the test to pass or fail. I am basing this on the xUnit terminology. This could have lead to some discussion about state testing verses behavior / interaction testing.
The answer they may have been looking for is: That a mock object is different than a stub. A stub emulates a dependency for the method under test. A stub shouldn't cause a test to fail. A mock does this and also checks how and when it is called. Mocks cause a test to pass or fail based on underlying behavior. This has the benefit of being less reliant on data during a test, but tying it more closely to the implementation of the method.
Of course this is speculation, it is more likely they just wanted you to describe the benefits of stubbing and DI.
To take a slightly different approach (as I think mocks have been nicely covered above):
"Take a database--if you're writing test code, you may not want that test hooked up live to the production database where actual operations will be performed."
IMO a bad way of stating the example use. You would never "hook it up to the prod database" during testing with or without mocks. Every developer should have a developer-local database to test against. And then you would move on test environments database then maybe UAT and finally prod. You are not mocking to avoid using the live database, you are mocking in order that classes that are not directly dependent on a database do not require you to set up a database.
Finally (and I accept I might get some comments on this) IMO the developer local database is a valid thing to hit during unit tests. You should only be hitting it while testing code that directly interacts with the database and using mocks when you are testing code that indirectly access the database.
I understand the need to test a class that has logic (for instance, one that can calculate discounts), where you can test the actual class.
But I just started writing unit tests for a project that will act as a repository (get objects from a database). I find myself writing a 'fake' repository that implements an ISomethingRepository interface. It uses a Dictionary<Guid, Something> for storage internally. It implements the Add(Something) and GetById(Guid) methods of the interface.
Why am I writing this? Nothing I'm writing will actually be used by the software when it's deployed, right? I don't really see the value of this exercise.
I also got the advice to use a mock object that I can setup in advance to meet certain expectations. That seems even more pointless to me: of course the test will succeed, I have mocked/faked it to succeed! And I'm still not sure the actual software will perform as it should when connecting to the database...
confused...
Can someone point me in the right direction to help me understand this?
Thank you!
You are not testing your mock object but some other class that is interacting with it. So you could for example test that a controller forwards a save method call to your fake repository. There is something wrong if you are "testing your fake objects"
Don't test the mock class. Do test the production class using the mock class.
The whole point of the test support class is to have something that you can predict its behavior. If you need to test the test support class in order to predict its behavior, there is a problem.
In the fake database article you linked in a comment, the author needs to unit test his fake database because it is his product (at least in the context of the article).
Edit: updated terms to be more consistent.
Mock - created by mocking framework
Fake - created manually, might actually function some.
Test Support - Mocks, Fakes, Stubs, and all the rest. Not production.
The purpose of the mock/stub object is not to be tested instead of the unit you're trying to test, it's to allow you to test that unit without needing other classes.
It's basically so that you can test classes one at a time without having to test all the classes they're also dependent on.
You should not be testing the mock class.
What you normally do is: you create mock classes for all the classes that the class you are testing interact with.
Let's say you are testing a class called Bicycle which takes in the constructor objects of classes Wheel, Saddle, HandleBar,etc.
And then within the class Bike you you want to test test its method GetWeight which probably iterates through each part and calls property/method Weight of them and then returns the total.
What you do:
you write a mock class for each part
(Wheel, saddle etc) which simply
implements the Weight bit
then you pass those mock classes to the Bicycle
test the GetWeight method on the Bicycle class
It that way you can focus on testing the GetWeight on the Bicycle class, in a manner that is independent on other classes (say they are not implemented yet, not deterministic etc.)
Who watches the watchers?
It is interesting for example if the mock implementation throws specific Exceptions for the corner cases, so you know that the classes that use or depend the IRepositorySomething can handle the exceptions that are thrown in real life. Some of these exceptions you can't generate easily with a test database.
You do not test the Mock object with a unit test, but you use it to test classes that depend on it.
Instead of writing a fake class by yourself, you can use a tool (like Rhino or Typemock) to mock it. It is much easier than writing all the mocks yourself. And like others said, there's no need to test fake code, which is no code if you use the tool.
I have actually found two uses for the mock classes that we use in repository implementation testing.
The first is to test the services that use an implementation of the "ISomethingRepository" equivalent that you mention. However, our repository implementations are created by a factory. This means that we do write tests against the "ISomethingRepository", but not against the "MockSomethingRepository" directly. By testing against the interface, we can easily assert that the code coverage for our tests cover 100% of the interface. Code reviews provide simple verification that new interface members are tested. Even if the developers are running against the mock that the factory returns, the build server has a different configuration that tests against the concrete implementation that the factory returns within the nightly builds. It provides the best of both worlds, in terms of test coverage and local performance.
The second use is one that I am surprised that no one else has mentioned. My team is responsible for the middle tier. Our web developers are responsible for the front end of the web products. By building out mock repository implementations, there is not the artificial obstacle of waiting for the database to be modeled and implemented prior to the front-end work starting. Views can be written that will be built off of the mock to provide a minimal amount of "real" data to meet the expectations of the web developers, as well. For example, data can be provided to contain minimum and maximum length string data to verify that neither break their implementation, etc.
Since the factories we use are wired as to which "ISomethingRepository" to return, we have local testing configurations, build testing configurations, production configurations, etc. We purposely are trying to make sure that no team on the project has unreasonable wait times because of another team's implementation time. The largest chunk of wait time is still provided by the development team, but we are able to crank out our domain objects, repositories, and services at a faster pace than the front-end development.
Of course, YMMV. ;-)
You write "fake" class called Stub or Mock object because you want to test an implementation in a simple way without testing the real concrete class. The purpose is to simplify the testing by testing only the Interface (or abstract class).
In your example, you are testing something that has a dictionnary. It might be fill up in real by the database or have a lot of logic behind it. In your "fake" object, you can simplify everything by having all data constant. This way you test only the behavior of the interface and not how the concrete object is built.
There is generally no need to run classical unit tests in the Data Access Layer.
Perhaps you can write integrational style unit test for your Data Acess Classes, that is, Integration Test (= integrating your Data Access Layer Code with the DB) using the features of Unit Testing Frameworks.
For example, in a Spring project you can use Spring Testcontext to start your Spring context inside a unit test, and then connect to a real database and test that the queries returns correct results. You need probably an own database for unit tests, or perhaps you can connect them with a developer DB.
Have a look at the following article for a good explanation of this:
https://web.archive.org/web/20110316193229/http://msdn.microsoft.com/en-us/magazine/cc163358.aspx
Basically, if you write a fake object and it turns out to be fairly complex, it is sometimes worth it to unit test the fake to make sure it works as expected.
Since a repository can be complex, writing unit tests for it often makes sense.