Showing posts with label Fakes Framework. Show all posts
Showing posts with label Fakes Framework. Show all posts

Friday, July 5, 2013

[Visual C#] How to test your applications using the Fakes Framework (3/3)

In this blog post of the series I am going reproduce the same test scenarios as shown in my last blog post. Only this time, I will not modify the initial source code to make it testable but instead use the Fakes Framework Shims to test it as it is.

Fakes Framework Sims

Note that Shims get generated the same way as Stubs and that they can also be restricted by applying filters in the SampleCode.fakes xml file.

The internal mechanisms are however quite different and innovative. They even differ from other existing mocking frameworks. So how does it work ? In fact, original method calls are intercepted and redirected at runtime to the methods that are defined in the associated Shims.

In our example, we are able to redefine the calls to the methods that are tightly coupled to external sources without any actual code modifications. As you might remember, the concerned methods are IsValid(…) and Save(…).

The first test could be expressed as follows when using Shims :

image

Here is an explanation of the unit test code for the example above using Shims :

  • We use a ShimsContext in a using block to limit its lifetime and to dispose it correctly. All calls to the IsValid(…) and SaveDeal(…) methods are only redirected if they are declared within the using block.
  • We do not use proxy classes anymore, instead we use the code that is implemented in the DealRepository constructor. However, we have to redefine the constructor code because in the original code we return an exception (see previous blog post of the series).
  • Methods can be “replaced” by other methods. Those replacement methods have an additional parameter, when compared to the original method. This parameter defines the instance of the object that undergoes the redirection.
  • The result is that the initial code has not been modified but we were able to isolate and test the TrySave(…) method nonetheless.

I would like to add that Shims can also be used for static classes, sealed classes, generics, etc.. as easy as I have shown above. You can even generate them for standard .NET framework classes, such as System.DateTime and System.Configuration.ConfigurationManager for example (with the exception of the classes that are in “mscorlib”  and “system”). This allows for some really powerful use cases.

Conclusion

The example has shown that using Shims for your unit tests is easier and quicker compared to Stubs. There are no software design requirements so it seems the preferable solution. But it has its drawbacks ! You miss the opportunity to improve your code. One of the main advantages of TDD gets lost: refactoring you code to produce good quality code.

So refactor your code and use Stubs whenever possible. If you cannot modify your code (you have legacy code) or if you need to mock .NET Framework.classes use Shims. The Fakes Framework is the only unit test framework  that provides both approaches at the same time. This is a real advantage when compared to RhinoMock or MoQ.


Share/Save/Bookmark

Wednesday, July 3, 2013

[Visual C#] How to test your applications using the Fakes Framework (2/3)

Now lets start using the Fakes Framework by implementing a real live scenario. In the following example I am going to show you some legacy code, which has some software design flaws. I am going to apply TDD and SOLID concepts to improve code quality and then use Fakes Framework Stubs for testing it.

Then in the next blog post of the series I am going to show you how to test source code without any code modifications by using Fakes Framework Shims. This is especially interesting for code that cannot be modified or that requires too many modifications and which is thus too expensive to improve.

Refactoring badly designed source code

The BusinessService class has the responsibility to store Deals in the database if they are valid :

image

As you see it uses two other business classes : the DealValidator class for deal validation and the DealRepository class for saving a deal to the database. If a deal is not valid an exception is thrown. Furthermore, a bool with the False value is returned, if a deal cannot be saved to the database.

Here are the implementations of the classes, without any actual source code. The methods only contain a not implemented exception. We are going to mock those objects later, so no need to implement them completely here. Even more, by doing it like this, we have the opportunity to validate that they are not actually called. We do not want to have them called, when we unit test the BusinessService class, since they are part of its external dependencies (as explained in the first part of the blog series).

image

The Deal class is a simple data transfer object (DTO) :

image

Lets analyze the software design of this simple example : the BusinessService class and the DealValidator, DealRepository and Deal classes are tightly coupled as it is implemented here. This is bad design and a violation of the SOLID principles. To be more specific it violates the Dependency Inversion Principle (DIP).

The first thing to do now, is to modify the code to make it adhere to the DIP principle and thus improving its quality. When applying TDD and writing unit tests, you have to isolate the code that has to be tested (System Under Test). So if we want to unit test all the methods of the class, we have to decouple its methods from the rest of the source code. In the end the DIP principle gets automatically respected.

To achieve this goal we are going to do some dependency injection. First we use Interfaces to serve as abstraction layer between the BusinessService class and the DealValidator, DealRepository and Deal classes :

image

The business classes and interfaces code looks now like this :

image

You are now ready to use the Fakes Framework to test your code. This is what we are going to do in the next step.

Fakes Framework Stubs

Now that the BusinessService class has been completely decoupled, we can use Fakes Framework Stubs for unit testing it. After creation of a new unit test project and after adding a reference to our business code project, we generate the Fakes Framework library by right-clicking on the reference and selecting “Add Fakes Assembly”.

image

Visual Studio 2012 automatically adds the following to the project :

image

  1. A library called CodeSample.Fakes, which contains the auto-generated Stubs and Shims classes. Those are going to be used as proxies in our unit tests.
  2. A reference to Microsoft.QualityTools.Testiong.fakes.dll, which contains all the core components of the Fakes Framework.
  3. A Fakes folder, that contains a file called xml CodeSample.fakes. This file allows to impact the automatic generation of Stubs and Shims.

For our example we declare that Stubs have only to be generated for Interfaces :

image

We may now implement unit tests using the Stubs that were auto-generated above in the CodeSample.Fakes.dll.

The following unit test will return True when the TrySave(…) method is called and a deal has been validated and saved (which is the case in our example) :

image

Lets see how that works in  detail : in the Setup step we initialize the IRepository and IValidator interfaces by using the corresponding Stubs. Note that the classname is “Stub” and then the name of the interface to substitute.

Then we simulate a save and validation operation that has been  successfully finished. To do that we define that the Save(…) and IsValid(…)  methods return always True.

In terms of naming conventions, methods are suffixed by the type name of their input parameters. In our example the IsValid(…) and Save(…) methods have both as input parameter IDataObjet, so they are named IsValidIDataObject(…) and SaveIDataObject(…).

Finally, we use the Stubs from above to instantiate a BusinessService object (also doing some constructor injection) and we test the TrySave(…) method to validate that the result is conform with our scenario.

In the next example, we test that the TrySave(…) methods calls a validator :

image

To achieve this, we are using the variable validatorWasCalled, which we initialize to the False value. The test is validating that the variable is set to True during the processing in the corresponding Stub when calling the TrySave(…) method.


Share/Save/Bookmark

Friday, June 28, 2013

[Visual C#] How to test your applications using the Fakes Framework (1/3)

As already mentioned on my blog multiple times, one of the ways of having good quality code is to use the Test Driven Development (TDD) approach. I have shown you how to apply the TDD using Visual Studio 2012 in a tutorial on my blog here.

When talking about TDD we have to talk about unit tests. Testing your code correctly can be very complicated sometimes and even nearly impossible to achieve. This is especially true for legacy code, which might not adhere to best practices such as loosely coupling and abstraction.

To help you with these kind of problems, Microsoft has created the Fakes Framework. It will aid you to create good unit tests for new code that you write (via Stubs) but also for legacy code (via Shims).

This blog series aims at presenting you the benefits of using the Fakes Framework. It can also be used as tutorial to start using it in your daily work.

What is a good unit test ? How to handle coupling to external sources ?

One of the main problems when writing unit tests is the dependency on external sources such as databases, external components, web services and even method calls within the same class.

For example, if you write a unit test that queries a database, how to handle data inconsistencies or database unavailability ? The unit test will fail in these cases, even if the code is implemented in an efficient and correct way ! This is due to the fact that the unit tests does not test the code in an atomic way, but instead it tests the code as well as all of its external dependencies. But conceiving and implementing atomic unit tests absolutely necessary to assure consistent and correct test results.

So how do we create unit tests that are independent from external sources ? We apply mocking ! This means replacing the real external sources by fake sources (also called Shims or Mocks) within your code. You do connect to the database anymore during your unit tests, for example. You substitute and mock the data objects (such as POCO, DataSet, DataTable, etc…) containing the database query results and your unit tests become decoupled.

We have solved one important problem, but we have added another since we need now to be able to create mock objects easily and quickly. Your unit tests will have better quality but if mock creation takes too much time it will have a negative impact on developer efficiency. The Fakes Framework allows for the automatic creation of mock objects, thus eliminating the cited problem.

What is the Fakes Framework ?

The Fakes Framework is the next generation of the Moles & Stubs project, which was created by Microsoft Research. Please note that the Moles & Stubs project is not supported in Visual Studio 2012 anymore, but you may very well use it in Visual Studio 2010 of course. The Fakes Framework is only included in Visual Studio 2012 Ultimate and you have to modify your existing Moles & Stubs code since it is not compatible out of the box. The basic functionalities are the same but nonetheless much has been improved and modified. The Moles are now called Shims for example !

By using the Fakes Framework development teams can create quickly and efficiently unit tests. Two different approaches are provided: Stubs and Shims.

Stubs are substitute objects that help to isolate the code that needs to be tested. To be able to use them correctly, you have to have loosely coupled classes in your code. This can be achieved by using interfaces for example. Stubs are very well adapted to new code.

Shims are very different, because they allow the interception of method calls during runtime. This allows mocking objects and function calls , which could normally not be done. Shims are very well adapted to legacy code.

Here is a comparison between Stubs and Shims and their provided functionalities:

Functionality

Stubs

Shims

Interception Mechanism

Virtual Methods

Runtime Instrumentation

Static Methods / Sealed

No

Yes

Internal Types

Yes

No

Private Methods

No

Yes

Static Constructor / Finalizers

No

Yes

Performance

Good

Low

Deployment

Xcopy

Installation

Abstract Methods

Yes

No


Share/Save/Bookmark

Tuesday, March 12, 2013

[Guide] Visual Studio Test Tooling Guidance
Better Unit Testing with Microsoft Fakes

The ALM Rangers have recently published a guide on their page “Visual Studio Test Tooling Guidance” with best practice on Unit Testing and the Microsoft Fakes Framework with thorough examples and Hands-On Labs called “v1.0 - Better Unit Testing with Microsoft Fakes”.

image

I really recommend looking into the guide since it contains a rich set of information on how to start using the Fakes Framework as well as how to use it in advanced scenarios.

And if you are already reviewing guides, please also take a look at all the other guides that are available on the site such as :

image

Happy reading and feel free to add comments with other guides that you find useful around software testing and especially the Microsoft Fakes Framework.

If you don’t know what the Microsoft Fakes Framework is, please stay tuned, since I am going to give you a first overview of its features and some examples in a future blog post series on this subject in the next weeks.


Share/Save/Bookmark

Friday, February 1, 2013

[Publication] Article in French Programmez Magazine on Fakes Framework with Visual Studio 2012

You can find an article of 4 pages on how use the Fakes Framework with Visual Studio 2012 in the French Programmez magazine No.160 written by Fathi Bellahcene and me.

First Page and Second Page (low resolution)

Third Page and Fourth Page (low resolution)

The article is written in French but as always I will write some English articles on my Blog in the next weeks. So stay tuned if you are interested in getting to know how the Fakes Framework can help you when you need to test your code (especially if you are keen on TDD).


Share/Save/Bookmark