Unit testing is Sitecore can be tricky. There are a lot of moving parts. And to truly be able to test, you need to somehow bring all of those parts into a test.
That's exactly what I'm attempting do.
At high-level we'll accomplish this by:
Let's do this. It's mostly screenshots and code samples anyways.
Create a new project in Visual Studio for the tests. Make sure it's a standard Class Library. Call it what you want, I like Fishtank.IntegrationTests.
A Class Library uses an app.config instead of a web.config. Hopefully, you're following best-practices and modifying your web.config indirectly via /App_Config/Include/
As rule, we want to make sure every config we drop in here is set to Copy.
We'll create a folder structure inside Fishtank.IntegrationTests, mimicking \Website\App_Config:
Now here comes a wee bit of magic. We need all of our config files in our IntegrationTests project but don't want to maintain two copies of them. For this we use Add As Link:
Repeat these step with the App_Config/Include, App_Config/Prefetch & App_Config/Security folders respectively.
One final step, super important. Highlight all the config files in each folder under App_Config change Copy to Output Directory setting to Copy if newer.
Be sure to Save All on the solution after doing this.
Notice all files have been added. They have a special icon indicating that they're linked.
NUnit is my test runner of choice. Feel free to divert from the step is you have your own favorite. Here are the steps.
In your Integration project, under References, add a local reference to Sitecore.Kernel.dll & Sitecore.Nexus.dll. Make sure Copy Local is set to True for in the properties.
This step is bit of a dark art. We're make a class that executes before any test(s) are run. It reassigns Sitecore's file system to run from the IntegrationTests project build folder:
// In NUnit, this ensures it will run before any/all tests are executed
public class TestSetupFixture
public static SecurityDisabler _disabler;
public void SetupTest()
// This grounds Sitecore in the current directory so when
// Sitecore.IO.FileUtil.MapPath runs, it can find the files.
State.HttpRuntime.AppDomainAppPath = Directory.GetCurrentDirectory();
// This static. Allows it live, avoiding garbage collection
_disabler = new SecurityDisabler();
// If you need to run pipelines do it hear.
//CorePipeline.Run("initialize", new PipelineArgs());
// Set any properties you need in content
catch (Exception ex)
If you don't use NUnit, you'll have to find an equivalent methodology. Or simply run the above code manually at the start of your tests.
Now we'll create a test to prove that we're up and running. Let's call it SimpleTests.cs. Decorate the class as a [TestFixture] and the test method with [Test].
This test will prove the following:
public class SimpleTests
public void ShouldFindTheHomeNode()
// Get getfishtank is declared under:
// Pull the start path of the site
string startPath = Sitecore.Context.Site.StartPath;
// Pull the database name
string databaseName = Sitecore.Context.Site.Database.Name;
// Load the web database, and get item
var db = Sitecore.Data.Database.GetDatabase("web");
var item = db.GetItem("/sitecore/content/fishtank/home");
// Found the home node
// Paths of the home items match
// Database name pulled from context matches too
For proof, this is the best I can reasonably do.
An all encompassing screenshot showing:
If your file system paths in your web.config are absolute, they may need adjusting. Prefixing paths with a dot ./App_Config/ is all that's usually required. Definitely beware of the paths.
Also - be sure to Rebuild your IntegrationTests project in Visual Studio before you run your tests. The Rebuild copies your App_Config folder to the tests bin folder. For some reason, running tests using NUnit doesn't copy them.
If you this is your problem, you'll see these errors:
TestFixtureSetUp failed in TestSetupFixture
Exception doesn't have a stacktrace
Could not find a part of the path 'C:\getfishtank\Fishtank.IntegrationTests\bin\Debug\app_config\prototypes.config'.
To recap fundamental principles here:
This looks like a bit of work but once you understand the steps, it's quick process. And being able to test with a context and all your configs is defintely worth the effort.
Technically, we could deliniate between integration tests and unit tests. Connecting to Sitecore makes this approach integration testing as opposed to unit testing. Unit testing has no external dependency. That distinction may or may not be relevant to you.
If you have any questions or comments please leave them below or reach me on twitter at @dancruickshank. I'm happy to help.
This post was authored using Markdown for Sitecore.