Should model classes be tested?
Model classes does not contain logic, but usually contains some logic in the constructor for initialization.
These class are also shared, therefore it a very important that these class initializes correctly.
What is the standard for testing, should model classes be tested? Or the class that make use of them have responsibility to test them?
If you care whether code works or not, it should be tested. That applies to all code.
Given that, if your model code is getting exercised when you run other tests, it may not be necessary to have tests specific to your models. However, tests are relatively cheap to write and potentially pay off big dividends, so there's no reason not to write a few quick tests for your models.
The point is model classes should contain all the logic, according to Model-View-Controller design pattern. Remember -
Thinner views, thin controllers, fat models.
Tutorial
So, by that principle all business logic should be contained in the models. Thereby, models should be thoroughly tested.
Besides, data is the most important component in any web project. Thereby, ensuring models have sufficient validations, and they don't allow junk data into db is extremely crucial.
That's what MVC says. Although I agree that trying to fit everything into MVC constructs is a very common antipattern. An even better approach would be to use distinct classes to maintain business logic which don't fall into any MVC constructs, although they must be encapsulated in models too.
Besides, as far as testing is concerned is general, I believe any working piece of code should have atleast modest test suite for them. Tests are working specifications of the code or rather they should be. They guides some else on what your code is doing, how to change it without breaking anything.
Note:- Don't test your libraries though i.e. don't test django code or mongoengine
No.
Such test provide little to no value as you will be creating model instances in other tests, for components that work with/use said models. As such, you don't need dedicated model tests because they will be tested indirectly many, many times.
As i dig deeper in to the DbContext, DbSet and associated interfaces, I am wondering why you would need to implement a separate "Generic" Repository around these implementations?
It looks like DbContext and IDbSet do everything you need and include the "Unit Of Work" inside DbContext.
Am I missing something here or does it seem people enjoy adding another layer of dependency for no reason.
You are actually right. DbContext is an implementation of the unit of work pattern and IDbSet is an implementation of the repository pattern.
Repositories are currently very popular and overused. Everybody use them just because there are dozens of articles about creating repository for entity framework but nobody actually describes challenges related to this decision.
Main reasons for using repository are usually:
Hide EF from upper layer
Make code better testable
The first reason is some kind of architectonic purity and great idea that if you make your upper layers independent on EF you can later on switch to other persistence framework. How many times did you see such thing in the real world? This reason makes working with EF much harder because your repository must expose a lot of additional features wrapping what EF allows by default.
In the same time wrapping EF code can keep your code better organized and following Separation of concern rule. For me this can be the only real advantage of repository and unit of work but you have to understand that following this rule with EF will maybe make your code better maintainable and better readable but in the initial effort to create your application will be much higher and for smaller applications this can be unnecessary complexity.
The second reason is partially correct. The big disadvantage of EF is rigid architecture which can be hardly mocked so if you want to unit test upper layer you must wrap EF somehow to allow mocking its implementation. But this has many other consequences which I described here.
I follow Ayende's blog. If you ever used NHibernate you probably know his articles. This guy recently wrote several articles against using repository with NHibernate but NHibernate is much better mockable.
I am struggling with the same issues, and mockability for unit testing of the EF layers is important. But I ran across this great article which explains how to set up the EF 4.1 DbContext to be mockable by making sure your derived DbContext implemented a generic interface and exposes IDbSet rather than DbSet's. Since I am using a Database First approach, because our database already exists, I simply modified the T4 templates used to generate my derived DbContext to generate it to return IDbSet interfaces, as well as derive from my generic interface. That way the entire thing can be easily mocked, and you don't need to implement your own Unit Of Work or repository pattern. Just write your service code to consume your generic interface, and when you go to unit test it, just mock the generic interface with specific test data and you are good to go.
http://refactorthis.wordpress.com/2011/05/31/mock-faking-dbcontext-in-entity-framework-4-1-with-a-generic-repository/
One reason for creating the repository is so you can hide the implementation of DBSet and DbContext if you decide to move from EntityFramework to something else or vice versa.
For example, I was using NHibernate and I wrapped all of the calls to that framework inside my repository classes. They return IEnumerable for their gets to be "generic" and my repositories have the standard CRUD operations (update, delete, etc). I have long since moved to Entity Framework. Upon doing so, I did not need to change anything in my ViewModel classes or beyond because they pointed to my repository--I only needed to change the inside of my repository. This made life much easier when migrating.
(I used NHibernate because we are connecting to the ISeries, and at the time, there were no cost affective implementations using EF with the ISeries. The only one available was to pay $12,000 to IBM for their DB2Connect)
I'm starting a new project and I want to use unit testing.
So I wrote my services classes which are implementing interface and waiting for interface in their parameters so I can easily mock these classes.
My question: there is absolutely no code in my business class! (like Customer)
Is it normal? is it normal even without unit test ? what kind of code would you put in a class like "Customer"?
No, it doesn't sound normal to me - unless you are at the very beginning of your project and Customer is as yet just a skeleton, and you know it will get more functionality over time.
Otherwise it may be a sign of a design issue, such as an anemic domain model.
It is not the unit tests' fault. Unit tests don't in any way enforce one to create dumb classes without real functionality.
I don't know if normal is the right word here, I'd rather say that the situation you have found yourself in is very common.
I see this happen most often with people starting in on Domain Driven Design and also when people use design patterns such as MVVM - all the logic falls into services and controllers and managers (which are themself a smell IMO), and the core domain model becomes a very anaemic set of DTOs.
What I would suggest is returning to your object modelling and looking at your services and seeing where you have removed logic from your Customer object which is actually a core concern of the customer. That is - what does the customer object do? Some of this will belong in external services, but there will also be key processes which are the domain of the customer.
When you design clearly, there might be the case, where some classes are just aggregates of Data. This is part of the MVC Pattern, where the models should not contain much logic. However if you do have absolutely no code in your classes there is something seriously wrong.
To me it sounds, like you are trying some kind of dependency injection, but you are not only injecting the dependencies, but rather everything. This is taking the pattern to far, so it might be becoming it's own anti-pattern.
Reading this question has helped me solidify some of the problems I've always had with unit-testing, TDD, et al.
Since coming across the TDD approach to development I knew that it was the right path to follow. Reading various tutorials helped me understand how to make a start, but they have always been very simplistic - not really something that one can apply to an active project. The best I've managed is writing tests around small parts of my code - things like libraries, that are used by the main app but aren't integrated in any way. While this has been useful it equates to about 5% of the code-base. There's very little out there on how to go to the next step, to help me get some tests into the main app.
Comments such as "Most code without unit tests is built with hard dependencies (i.e.'s new's all over the place) or static methods." and "...it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class [...] and so on." have made me realise that the next step is understanding how to de-couple code to make it testable.
What should I be looking at to help me do this? Is there a specific set of design patterns that I need to understand and start to implement which will allow easier testing?
Here Mike Clifton describes 24 test patterns from 2004. Its a useful heuristic when designing unit tests.
http://www.codeproject.com/Articles/5772/Advanced-Unit-Test-Part-V-Unit-Test-Patterns
Pass/Fail Patterns
These patterns are your first line of defence (or attack, depending on your perspective) to guarantee good code. But be warned, they are deceptive in what they tell you about the code.
The Simple-Test Pattern
The Code-Path Pattern
The Parameter-Range Pattern
Data Transaction Patterns
Data transaction patterns are a start at embracing the issues of data persistence and communication. More on this topic is discussed under "Simulation Patterns". Also, these patterns intentionally omit stress testing, for example, loading on the server. This will be discussed under "Stress-Test Patterns".
The Simple-Data-I/O Pattern
The Constraint-Data Pattern
The Rollback Pattern
Collection Management Patterns
A lot of what applications do is manage collections of information. While there are a variety of collections available to the programmer, it is important to verify (and thus document) that the code is using the correct collection. This affects ordering and constraints.
The Collection-Order Pattern
The Enumeration Pattern The
Collection-Constraint Pattern
The Collection-Indexing Pattern
Performance Patterns
Unit testing should not just be concerned with function but also with form. How efficiently does the code under test perform its function? How fast? How much memory does it use? Does it trade off data insertion for data retrieval effectively? Does it free up resources correctly? These are all things that are under the purview of unit testing. By including performance patterns in the unit test, the implementer has a goal to reach, which results in better code, a better application, and a happier customer.
The Performance-Test Pattern
Process Patterns
Unit testing is intended to test, well, units...the basic functions of the application. It can be argued that testing processes should be relegated to the acceptance test procedures, however I don't buy into this argument. A process is just a different type of unit. Testing processes with a unit tester provide the same advantages as other unit testing--it documents the way the process is intended to work and the unit tester can aid the implementer by also testing the process out of sequence, rapidly identifying potential user interface issues as well. The term "process" also includes state transitions and business rules, both of which must be validated.
The Process-Sequence Pattern
The Process-State Pattern
The Process-Rule Pattern
Simulation Patterns
Data transactions are difficult to test because they often require a preset configuration, an open connection, and/or an online device (to name a few). Mock objects can come to the rescue by simulating the database, web service, user event, connection, and/or hardware with which the code is transacting. Mock objects also have the ability to create failure conditions that are very difficult to reproduce in the real world--a lossy connection, a slow server, a failed network hub, etc.
Mock-Object Pattern
The Service-Simulation Pattern
The Bit-Error-Simulation Pattern
The Component-Simulation Pattern
Multithreading Patterns
Unit testing multithreaded applications is probably one of the most difficult things to do because you have to set up a condition that by its very nature is intended to be asynchronous and therefore non-deterministic. This topic is probably a major article in itself, so I will provide only a very generic pattern here. Furthermore, to perform many threading tests correctly, the unit tester application must itself execute tests as separate threads so that the unit tester isn't disabled when one thread ends up in a wait state
The Signalled Pattern
The Deadlock-Resolution Pattern
Stress-Test Patterns
Most applications are tested in ideal environments--the programmer is using a fast machine with little network traffic, using small datasets. The real world is very different. Before something completely breaks, the application may suffer degradation and respond poorly or with errors to the user. Unit tests that verify the code's performance under stress should be met with equal fervor (if not more) than unit tests in an ideal environment.
The Bulk-Data-Stress-Test Pattern
The Resource-Stress-Test Pattern
The Loading-Test Pattern
Presentation Layer Patterns
One of the most challenging aspects of unit testing is verifying that information is getting to the user right at the presentation layer itself and that the internal workings of the application are correctly setting presentation layer state. Often, presentation layers are entangled with business objects, data objects, and control logic. If you're planning on unit testing the presentation layer, you have to realize that a clean separation of concerns is mandatory. Part of the solution involves developing an appropriate Model-View-Controller (MVC) architecture. The MVC architecture provides a means to develop good design practices when working with the presentation layer. However, it is easily abused. A certain amount of discipline is required to ensure that you are, in fact, implementing the MVC architecture correctly, rather than just in word alone.
The View-State Test Pattern
The Model-State Test Pattern
I'd say you need mainly two things to test, and they go hand in hand:
Interfaces, interfaces, interfaces
dependency injection; this in conjunction with interfaces will help you swap parts at will to isolate the modules you want to test. You want to test your cron-like system that sends notifications to other services? instanciate it and substitute your real-code implementation for everything else by components obeying the correct interface but hard-wired to react in the way you want to test: mail notification? test what happens when the smtp server is down by throwing an exception
I myself haven't mastered the art of unit testing (and i'm far from it), but this is where my main efforts are going currently. The problem is that i still don't design for tests, and as a result my code has to bend backwards to accomodate...
Michael Feather's book Working Effectively With Legacy Code is exactly what you're looking for. He defines legacy code as 'code without tests' and talks about how to get it under test.
As with most things it's one step at a time. When you make a change or a fix try to increase the test coverage. As time goes by you'll have a more complete set of tests. It talks about techniques for reducing coupling and how to fit test pieces between application logic.
As noted in other answers dependency injection is one good way to write testable (and loosely coupled in general) code.
Arrange, Act, Assert is a good example of a pattern that helps you structure your testing code around particular use cases.
Here's some hypothetical C# code that demonstrates the pattern.
[TestFixture]
public class TestSomeUseCases() {
// Service we want to test
private TestableServiceImplementation service;
// IoC-injected mock of service that's needed for TestableServiceImplementation
private Mock<ISomeService> dependencyMock;
public void Arrange() {
// Create a mock of auxiliary service
dependencyMock = new Mock<ISomeService>();
dependencyMock.Setup(s => s.GetFirstNumber(It.IsAny<int>)).Return(1);
// Create a tested service and inject the mock instance
service = new TestableServiceImplementation(dependencyMock.Object);
}
public void Act() {
service.ProcessFirstNumber();
}
[SetUp]
public void Setup() {
Arrange();
Act();
}
[Test]
public void Assert_That_First_Number_Was_Processed() {
dependencyMock.Verify(d => d.GetFirstNumber(It.IsAny<int>()), Times.Exactly(1));
}
}
If you have a lot of scenarios to test, you can extract a common abstract class with concrete Arrange & Act bits (or just Arrange) and implement the remaining abstract bits & test functions in the inherited classes that group test functions.
Gerard Meszaros' xUnit Test Patterns: Refactoring Test Code is chock full of patterns for unit testing. I know you're looking for patterns on TDD, but I think you will find a lot of useful material in this book
The book is on safari so you can get a really good look at what's inside to see if it might be helpful:
http://my.safaribooksonline.com/9780131495050
have made me realise that the next step is understanding how to de-couple code to make it testable.
What should I be looking at to help me do this? Is there a specific set of design patterns that I need to understand and start to implement which will allow easier testing?
Right on! SOLID is what you are looking for (yes, really). I keep recommending these 2 ebooks, specially the one on SOLID for the issue at hand.
You also have to understand that its very hard if you are introducing unit testing to an existing code base. Unfortunately tightly coupled code is far too common. This doesn't mean not to do it, but for a good time it'll be just like you mentioned, tests will be more concentrated in small pieces.
Over time these grow into a larger scope, but it does depend on the size of the existing code base, the size of the team and how many are actually doing it instead of adding to the problem.
Design patterns aren't directly relevant to TDD, as they are implementation details. You shouldn't try to fit patterns into your code just because they exist, but rather they tend to appear as your code evolves. They also become useful if your code is smelly, since they help resolve such issues. Don't develop code with design patterns in mind, just write code. Then get tests passing, and refactor.
A lot of problems like this can be solved with proper encapsulation. Or, you might have this problem if you are mixing your concerns. Say you've got code that validates a user, validates a domain object, then saves the domain object all in one method or class. You've mixed your concerns, and you aren't going to be happy. You need to separate those concerns (authentication/authorization, business logic, persistence) so you can test them in isolation.
Design patterns help, but a lot of the exotic ones have very narrow problems to which they can be applied. Patterns like composite, command, are used often, and are simple.
The guideline is: if it is very difficult to test something, you can probably refactor it into smaller problems and test the refactored bits in isolation. So if you have a 200 line method with 5 levels of if statements and a few for-loops, you might want to break that sucker up.
So, start by seeing if you can make complicated code simpler by separating your concerns, and then see if you can make complicated code simpler by breaking it up. Of course if a design pattern jumps out at you, then go for it.
Dependency Injection/IoC. Also read up on dependency injection frameworks such as SpringFramework and google-guice. They also target how to write testable code.
Test patterns are design patterns. Both are intended to guide the construction of a piece of software.The basic test patterns that are used in software test automation are many in number and i have selected following:
"Fluent builder test pattern"
They are defined as
"A coding technique known as the "fluent builder pattern" forces the developer or test automation engineer to create the objects sequentially by invoking each setter function one at a time until all necessary properties are defined."
Fluent builder test pattern.
In the Field of Software test Automation where normally we use different automation frameworks for web based testing including Selenium, TestNG and Maven we have this test pattern. Although the fluent builder pattern isn't expressly used for unit tests but it describe how it might be useful in the organising steps. Two components make up a builder class and a number of clearly defined Set methods, each of which is in charge of changing just one aspect of the state of the produced object. In order to connect all method calls together, each of these methods returns the builder itself. A construct method uses the previously set state to create and output the objects. This Specific Test Pattern is used with a number of programming languages like C#, JAVA and Javascript. This Test Pattern is used in different testing frameworks like JUNIT, NUNIT for Asp.net.
Complex objects are a typical occurrence in our Test Scripts solutions. objects with numerous fields, each of which is challenging to construct. The Most Important Advantages of the Fluent Builder test Patterns are
1- The Code is more maintainable
2-The Code of the Automated Script is readable and simple to understand for Static reviews and Static analysis and even helpful for white box testing.
3-When you create an automated test script in any language like Java, the possibility for errors become less when you create objects for different methods.
Understanding the benefits of the builder pattern is one of the most crucial considerations you should make. As previously stated, if we design objects that are difficult to construct, your code will be of higher quality in those situations. When an object's function Object() { [native code] } takes more than a few parameters and those parameters are objects with nested classes, you should consider using this pattern.
Fluent Builder Test Patterns in Java:
Although it appears straightforward, there is a problem. If there are too many setters methods and the object development is complicated, the Test Engineer may frequently forget to use some of the setters as they construct the object. As a result, none of the setters for many significant object attributes are being called because many of them will be null.
Missing the set property can be an expensive procedure in terms of development and maintenance for many enterprise systems' fundamental entities, such as Order or Loan, which may be begun in many different areas of the code. We make the developer call all necessary setter methods before the build function is called.
In STLC(Software Testing Lifecycle):
We would have known that developing an automated test for an application is not particularly challenging if you were an automation engineer. Maintaining the current exams is challenging instead! When you have a large number of automated tests, that too. you also have junior team members who are responsible for maintaining the thousands of tests suite. In STLC (Software Testing Lifecycle),
We collaborate with others. We collaborate with other QA engineers who have a variety of skill sets! It could be really challenging for some team members to comprehend the code. You might assume that they would be less productive the longer they spent trying to grasp the code. You must develop an appropriate architecture for the page objects and tests as the lead architect of the automation framework to make maintenance simple and code reusibility as well. So everyone in the STLC is familiar and have a good understanding of the framework
Try utilising the fluent builder pattern if setting up the state for multiple unit tests is a bit messy or hard. It is now very easy to read the test state. Because a single function on the builder could encapsulate a lot of state-setup code that can be written once and used by multiple tests, employing the fluent builder pattern in unit tests in some circumstances can assist to prevent code duplication.
I would like to know what are your practices when you test your classes.
For example, I like to use inheritance, with my fixtures.
Given two classes BaseClass, SubClass, I make two other classes BaseClassFixture and SubClassFixture (SubClassFixture is a sub class of BaseClassFixture). So I'm sure that I don't break code which use SubClass as a BaseClass (And people who extends my class can be sure if they do things right, by creating another sub class of my fixture).
I do fixture inheritance with interfaces too.
For example, when I create a fixture for IList, I check that any Add, increase Count by one.
When I have a concrete class which implements IList I just create a fixture named MyConcreteClassIListFixture.
In that case, the fixture for my interface is abstract and I let my subclass create the instance for my tests.
I think it's a kind of design by contracts (see Bertrand Meyer), because I check invariant before and after any tests.
I do this especially with published interfaces or classes.
And you... what are your practices ??
My most important rule is that each test should be atomic and should run in no particular order.
For unit tests, they should strictly obey seperation of concerns.
For integration tests, I pay extra attention to make sure they follow the most important rule.
Also, tests should follow the DRY rule as much as possible along with the code.
There are couple of important things when writing unit test.
1) Unit Tests should be independent:
Unit Tests must be independent. This means that your unit test should not depend on external things to run. This includes internet connection, external web services etc.
2) Unit Tests should be fast:
Unit Tests should run fast. You can write unit tests in multiple ways. Some of them include the dataaccess even though you don't need to access data to run the test. You can always use mock objects and mock the data access layer.
3) Good naming convention:
Unit Tests should have good naming convention and should read like stories.
Here is one example:
public class when_user_transfer_money_from_source_account_to_destination_account
public void make_sure_error_is_thrown_when_source_account_has_insufficient_funds()
{
}
Here is a good screencast that covers many of the above points:
http://screencastaday.com/ScreenCasts/32_Introduction_to_Mocking.aspx