From personal experience: they have made a huge step forward from v6 to v7, but there is still to go. I would try to focus on areas where more "testable API" is used and reconsider once again about possible tests where "less testable API" are used. I would try to figure out what excatly should be tested and where it's worth to add mocks in order to get tests running. Maybe I would need to test ValidateUser() method out of LoginExisting() context and do more granular test in order to get around localization service in this case.

In summary: yes, there is still path to go and more testable / mockable / shimable / whatver API should be added, but on the another hand I can truly understand EPiServer that this is a long way to go with all the consequences around.

And btw, when you say "static methods ... are hard to test and unmockable" is it so that you cannot change behavior of the static properties / methods? You may look into Fakes library - it has interesting capabilities:

[TestMethod]
public void TestMethod1()
{
    using (ShimsContext.Create())
    {
        var mock = new Mock<LocalizationService>(null);
        mock.Object.Arrange(s => s.GetString(Arg.AnyString)).Returns(Arg.AnyString);

        ShimLocalizationService.CurrentGet = () => mock.Object;
        var result = CallSampleMethod();

        Assert.Equals(result, "sample-key");
    }
}

private string CallSampleMethod()
{
    return LocalizationService.Current.GetString("sample-key");
}

Hi Valdis,

thank you for your answer. Yeah, I was lurking around and gathering information about the Microsoft Fakes framework as the solution to my issues. Unafortunately it is only available in Visual Studio Premium and my company only has available the Professional version.

I guess I'll have to stick to wrappers over the API and refactor existing code to make it more testable until EPiServer becomes more Test-friendly :)

And what about integration tests on a real environment? How can I set up all the EPiServer initialization from a unit test project?

When it comes to integration tests you have to make sure that test project has all the configs EPiServer will need at some point. The best way we found in actually decomplie EPiServer.Global type and look for hints how to setup required configuration. You just need to pull in stuff you need.

For instance DDS init:

var container = new Container(); 
var factory = new SqlDatabaseFactory(); 
container.Configure(ce => ce.For<IDatabaseHandler>().Use(factory.CreateDefaultHandler)); 
ServiceLocator.SetLocator(new StructureMapServiceLocator(container)); 
DataInitialization.InitializeFromCode(container, factory, null); 
var store = typeof(SampleModel).GetStore(); 

Part of Commerce init:

var container = new Container();
var context = new ServiceConfigurationContext(HostType.Service, container);
new CommerceInitialization().ConfigureContainer(context);

var factory = new SqlDatabaseFactory();
container.Configure(ce => ce.For<IDatabaseHandler>().Use(factory.CreateDefaultHandler));

var locator = new StructureMapServiceLocator(container);
ServiceLocator.SetLocator(locator);

Pull stuff you need. Look for various implementations of IInitializableModule or IConfigurableModule.

And when it comes to Fakes - AFAIK assembly generation is available in Premium, you can generate those and use in Professional, but yes - Fakes should be available to everyone, otherwise Microsoft is preventing to use some sort of Tdd disciplines.. :)

I don't think that installing VS Premium just for Fakes is an option to me... So I think I'll stick with refactor and making code somewhat more testable and maintainable.

About the integration tests, I'll try your suggestion and come back with the results.

Thank you very much for your support

Use ex. Moq for mocking. remember that you can also mock the servicelocator, so if you make sure you use the EPiServer.ServiceLocation.ServiceLocator.Current for all your service instantiation, you can atleast mock most calls to episerver functionality when you test your code.