//class = Person
public string Name { get; internal set; }
I have an object with several different fields that are declared as shown above. I would like to use Moq so I can unit test the repository. The repository simply returns a list of names, so I would like to setup Moq to work with it like so:
var personRepositoryMock = new Mock<IPersonRepository>();
personRepositoryMock
.Setup(p => p.GetNames())
.Returns(new List<Person>
{
new Person{Name = "Hulk Hogan"}
});
Being new to mocking and unit testing in general, I have a couple of questions:
What are my options to stub out the Person class in my scenario?
What is the benefit of mocking in this situation? I read and read and read, but I can't seem to get my head around why I see examples like this, testing a repository. Mocks make sense to me when I have to unit test business logic, but not so much in the data layer. Any words of wisdom to clear this up for me?
Thanks.
1) You can use the "InternalsVisibleTo" attribute on the assembly (in AssemblyInfo.cs) that contains the repository class, to give the Moq assembly access to it.
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
[assembly: InternalsVisibleTo("YourTestClass")]
2) Mocking decouples your data layer from being a dependency requirement for unit tests.
Think of it this way: you won't be creating a Mock to test the repository itself. You're creating the mock for other classes to use as a fake data source, to test their functionality that requires input data from the repository in the real application.
If you can accurately predict the data cases that your repository will provide, then you can mock those cases as fake input, and not require that your unit tests actually connect to the database to get live data to use.
Your example won't actually unit test anything in the repository (other than the parameterless constructor!) so ... I don't know where you're seeing these examples, but I don't feel that the code above is providing anything useful "as is".
Related
One of the definition of ninject in internet is;
"Somewhere in the middle of your application, you're creating a class
inside another class. That means you're creating a dependency.
Dependency Injection is about passing in those dependencies, usually
through the constructor, instead of embedding them."
what i want to learn is, where ever we see a creation of a class inside another class should we use ninject or just we should use in some part of program that we want/need to apply loosely coupling for design purposes because maybe we would like to use different approaches in the future?
Sorry if this is a silly question.
It's a perfectly valid question, and there are no absolute right or wrong answers. Ninject and other IoC frameworks are designed to de-couple dependencies.
So the moment you do this:
public class MyClass1
{
public MyClass1()
{
MyClass2 mc2 = new MyClass2();
}
}
You can categorically say that MyClass1 has a dependency in MyClass2.
For me, my rule is this: do I need to unit test MyClass1, or is it likely I'll need to unit test MyClass1?
If I don't need to unit test it, then I don't find much value in decoupling the two classes.
However, if I do need to unit test MyClass1, then injecting in MyClass2 gives you much better control over your unit tests (and allows you to test MyClass1 in isolation).
You do need to evaluate each case separately though. In the above example, if I need to unit test MyClass1, and MyClass2 is just a basic string formatting class, then I probably wouldn't decouple it. However, if MyClass2 was an email sending class then I would de-couple it. I don't want my unit tests actually sending emails, so I would feed in a fake for my tests instead.
So I don't believe there are any solid rules, but hopefully the above gives you a better idea of when you might decouple, and when you might not decouple.
I fully understand the idea of the design of Repository pattern. But why do we need to implement the iDepository interface class? What particular use is this for?
The repository class itself works without the interface class.
I think someone is going to answer me it's for decoupling from the business logic and the data logic.
But even if there is no interface class, isn't the data logic decoupled data logic?
It is so that you can inject a test double of the IRepository class when you are unit testing the business layer. This has the following benefits:
It allows you to easily pinpoint failing tests as being caused by the business layer rather than the repository layer;
It makes your business logic layer tests fast, as they depend neither on data access, which tends to be slow, nor set-up of a database structure and test data, which tends to be very slow.
One way to inject the test doubles when unit testing is by Constructor Injection. Suppose your Repository has the following methods:
void Add(Noun noun);
int NumberOfNouns();
And this is the code of your business class:
public class BusinessClass {
private IRepository _repository;
public BusinessClass(IRepository repository) {
_repository = repository;
}
// optionally, you can make your default constructor create an instance
// of your default repository
public BusinessClass() {
_repository = new Repository();
}
// method which will be tested
public AddNoun(string noun) {
_repository.Add(new Noun(noun));
}
}
To test AddNoun without needing a real Repository, you need to set up a test double. Usually you would do this by using a mocking framework such as Moq, but I'll write a mock class from scratch just to illustrate the concept.
public IRepository MockRepository : IRepository {
private List<Noun> nouns = new List<Noun>();
public void Add(Noun noun) {
nouns.Add(noun);
}
public int NumberOfNouns() {
return nouns.Count();
}
}
Now one of your tests could be this.
[Test]
public void AddingNounShouldIncreaseNounCountByOne() {
// Arrange
var mockRepository = new MockRepository();
var businessClassToTest = new BusinessClass(mockRepository);
// Act
businessClassToTest.Add("cat");
// Assert
Assert.AreEqual(1, mockRepository.NumberOfNouns(), "Number of nouns in repository should have increased after calling AddNoun");
}
What this has achieved is that you have now tested the functionality of your BusinessClass.AddNoun method without needing to touch the database. This means that even if there's a problem with your Repository layer (a problem with a connection string, say) you have assurance that your Business layer is working as expected. This covers point 1 above.
As for point 2 above, whenever you're writing tests which test the database you should make sure it's in a known state before each test. This usually involves deleting all the data at the beginning of every test and re-adding test data. If this isn't done then you can't run assertions against, say, the number of rows in a table, because you won't be sure what that's supposed to be.
Deleting and re-adding test data would normally be done by running SQL scripts, which are slow and vulnerable to breakage whenever the database structure changes. Therefore it's advisable to restrict the use of the database only to the tests of the repository itself, and use mocked out repositories when unit testing other aspects of the application.
As for the use of abstract classes - yes, this would provide the same ability to supply test doubles. I'm not sure which code you would choose to put in the abstract base and which the concrete implementation, though. This answer to an SO question has an interesting discussion on abstract classes vs interaces.
First, you must understand what the Repository pattern is. It's an abstraction layer so that rest of the application do not have to care where the data comes from.
Abstractions in .NET is typically represented by interfaces as no logic (code) can be attached to an interface.
As a bonus that interface also makes it easier for you to test your application since you can mock the interface easily (or create a stub)
The interface also allows you to evolve your data layer. You might for instance start by using a database for all repository classes. But later you want to move some logic behind a web service. Then you only have to replace the DB repository with a WCF repository. You might also discover that an repository is slow and want to implement a simply memory cache within it (by using memcache or something else)
I found a very useful msdn page demonstrating the idea of Repository and Test Driven Development
.
http://blogs.msdn.com/b/adonet/archive/2009/12/17/walkthrough-test-driven-development-with-the-entity-framework-4-0.aspx
I'm building a relatively simple webapp in ASP.NET MVC 4, using Entity Framework to talk to MS SQL Server. There's lots of scope to expand the application in future, so I'm aiming for a pattern that maximises reusability and adaptability in the code, to save work later on. The idea is:
Unit of Work pattern, to save problems with the database by only committing changes at the end of each set of actions.
Generic repository using BaseRepository<T> because the repositories will be mostly the same; the odd exception can extend and add its additional methods.
Dependency injection to bind those repositories to the IRepository<T> that the controllers will be using, so that I can switch data storage methods and such with minimal fuss (not just for best practice; there is a real chance of this happening). I'm using Ninject for this.
I haven't really attempted something like this from scratch before, so I've been reading up and I think I've got myself muddled somewhere. So far, I have an interface IRepository<T> which is implemented by BaseRepository<T>, which contains an instance of the DataContext which is passed into its constructor. This interface has methods for Add, Update, Delete, and various types of Get (single by ID, single by predicate, group by predicate, all). The only repository that doesn't fit this interface (so far) is the Users repository, which adds User Login(string username, string password) to allow login (the implementation of which handles all the salting, hashing, checking etc).
From what I've read, I now need a UnitOfWork class that contains instances of all the repositories. This unit of work will expose the repositories, as well as a SaveChanges() method. When I want to manipulate data, I instantiate a unit of work, access the repositories on it (which are instantiated as needed), and then save. If anything fails, nothing changes in the database because it won't reach the single save at the end. This is all fine. My problem is that all the examples I can find seem to do one of two things:
Some pass a data context into the unit of work, from which they retrieve the various repositories. This negates the point of DI by having my Entity-Framework-specific DbContext (or a class inherited from it) in my unit of work.
Some call a Get method to request a repository, which is the service locator pattern, which is at least unpopular, if not an antipattern, and either way I'd like to avoid it here.
Do I need to create an interface for my data source and inject that into the unit of work as well? I can't find any documentation on this that's clear and/or complete enough to explain.
EDIT
I think I've been overcomplicating it; I'm now folding my repository and unit of work into one - my repository is entirely generic so this just gives me a handful of generic methods (Add, Remove, Update, and a few kinds of Get) plus a SaveChanges method. This gives me a worker class interface; I can then have a factory class that provides instances of it (also interfaced). If I also have this worker implement IDisposable then I can use it in a scoped block. So now my controllers can do something like this:
using (var worker = DataAccess.BeginTransaction())
{
Product item = worker.Get<Product>(p => p.ID == prodName);
//stuff...
worker.SaveChanges();
}
If something goes wrong before the SaveChanges(), then all changes are discarded when it exits the scope block and the worker is disposed. I can use dependency injection to provide concrete implementations to the DataAccess field, which is passed into the base controller constructor. Business logic is all in the controller and works with IQueryable objects, so I can switch out the DataAccess provider object for anything I like as long as it implements the IRepository interface; there's nothing specific to Entity Framework anywhere.
So, any thoughts on this implementation? Is this on the right track?
I prefer to have UnitOfWork or a UnitOfWorkFactory injected into the repositories, that way I need not bother it everytime a new reposiory is added. Responsibility of UnitOfWork would be to just manage the transaction.
Here is an example of what I mean.
I have started thinking about adding some unit tests around some business logic in my project.
The first method that I would like to test is a method in my service layer that returns a list of child nodes for a given node.
The method looks like this:
public List<Guid> GetSubGroupNodes(string rootNode)
{
List<Tree> tree = ssdsContext.Trees.ToList();
Tree root = ssdsContext.Trees.Where(x => x.UserId == new Guid(rootNode)).FirstOrDefault();
return GetChildNodeIds(root, tree);
}
private List<Tree> GetChildNodes(Tree rootNode, List<Tree> tree)
{
kids.Add(rootNode);
foreach (Tree t in FindChilden(rootNode, tree))
{
GetChildNodes(t, tree);
}
return kids;
}
The way I'd imaginge testing something like this is to provide a fake Tree structure and then test that a providing a node returns the correct subnodes.
ssdsContext is an ObjectContext.
I've seen that its possible to extract and interface for the ObjectContext How to mock ObjectContext or ObjectQuery<T> in Entity Framework? but I've also read that mocking a DBContext is a waste of time Unit Testing DbContext.
I have also read that as Entity Framework is an implementation of the repository pattern and unit of work patten here: Generic Repository With EF 4.1 what is the point.
This has all left me a bit confused...is the only real way to test a method like this to create a Repository Layer? Is it even worth unit testing this method?
Wrap the ObjectContext class in a wrapperclass -- let's call it ContextWrapper for fun -- that only exposes what you need from it. Then you can inject an interface of this (IContextWrapper) in to your class with your method. A wrapper can be mocked with no hooks attached to the outside world. The treestructure, as you say, is easy to create, and get from your mock object. Thus making your test TRUE unittests instead of a kind of integration test.
so I think I'm perhaps not fully understanding how you would use an IOC container for doing Integration tests.
Let's assume I have a couple of classes:
public class EmailComposer : IComposer
{
public EmailComposer(IEmailFormatter formatter)
{
...
}
...
public string Write(string message)
{
...
return _formatter.Format(message);
}
}
OK so for use during the real application (I'm using autofac here) I'd create a module and do something like:
protected override void Load(ContainerBuilder containerBuilder)
{
containerBuilder.RegisterType<HtmlEmailFormatter>().As<IEmailFormatter>();
}
Makes perfect sense and works great.
When it comes to Unit Tests I wouldn't use the IOC container at all and would just mock out the formatter when I'm doing my tests. Again works great.
OK now when it comes to my integration tests...
Ideally I'd be running the full stack during integration tests obviously, but let's pretend the HtmlEmailFormatter is some slow external WebService so I decide it's in my best interest to use a Test Double instead.
But... I don't want to use the Test Double on all of my integration tests, just a subset (a set of smoke-test style tests that are quick to run).
At this point I want to inject a mock version of the webservice, so that I can validate the correct methods were still called on it.
So, the real question is:
If I have a class with a constructor that takes in multiple parameters, how do I make one of the parameters resolve to a an instance of an object (i.e. the correctly setup Mock) but the rest get populated by autofac?
I would say you use the SetUp and TearDown (NUnit) or ClassInitialize and ClassCleanup (MSTest) for this. In initialize you register your temporary test class and in cleanup you restore to normal state.
Having the DI container specify all the dependencies for you has the benefit of getting an entire object graph of dependencies resolved. However if there's a single test in which you want to use a different implementation I would use a Mocking framework instead.