Sitecore unit testing with test fixtures

Unit testing logic that uses the Sitecore content API is not very easy. Alistair Deneys has written some very good articles on it here and here. The second article describes how to use mocking. I prefer that approach over testing on a running Sitecore website (integration testing), because I want my tests to be fast and I don’t like the risk of breaking my Sitecore website by messing up the database.

But mocking can be very tedious. Having to setup all the mocks for your tests can take a lot of time and that may be used as an excuse not to unit test your code at all. Setting up large test fixtures can be very time consuming as well.

Since I recently made a Sitecore DataProvider, I’ve gotten somewhat familiar with that concept. So now I created a DataProvider that works in-memory. On startup, it loads Sitecore items from sources like Sitecore packages and serialized data (should work with TDS items as well). That should make it much easier to create test fixtures with your own items and templates! After your tests have run, your changes will be lost. That way, your tests can never ‘harm’ any database.

I’ve shared the code here on GitHub (I wanted to try GitHub). Here are some steps to help you set things up:

1. Download the project or pull it from GitHub.
2. Make sure all the project references are working.
3. Edit the SampleTestProject.dll.config file and change the absolute paths to correspond with the paths on your machine.
4. Run the unit tests in SampleTestProject (they should pass).

There are three projects in the solution:

1. FixtureDataProvider – This is the project that contains the DataProvider. If you inherit your unit testing class from SitecoreUnitTestBase, then some basic Sitecore stuff will be configured for you before the tests are executed.
2. SampleSitecoreProject – This project contains some logic that utilizes the Sitecore content API. More specifically, it can read KML and makes Sitecore items for every Placemark (containing a description and the coordinates of the placemark):
3. SampleTestProject – This project contains the SampleTestProject.dll.config file, which is kind of like a very minimal Web.config (without the need for an actual website to be running). The project also contains a data folder that has some serialized items and a zip package (the test fixture data). And you’ll also find some KML files to be imported. The UnitTest class contains the test of the previous code:

Some important points I want to make:

• Events and cache are disabled by default. So if you need to test those aspects, you’ll have to do some extra work.
• Though I attempted to emulate the SQL DataProvider as much as possible, I can not guarantee that it behaves in the exact same way at all times. Remember that unit testing can never replace integration testing and functional testing altogether.
• I have not yet implemented support for media (I might add support for that later, and for the MongoDB DataProvider as well). – Implemented (not yet for the MongoDB DataProvider)

Happy testing! And let me know if you have any questions or ideas!