« Archives in June, 2012

Sitecore unit testing with test fixtures – media library support added

I recently wrote a post on Sitecore unit testing with test fixtures. I’ve now added support for the media library (updated in the project on GitHub).

So now, you can also unit test code that imports an image into the media library.

And here’s some code to check if it works correctly.

T-SQL pocket knife code

Sometimes I like to dive into the SQL databases that hold all of our precious Sitecore content and go wild. No really; sometimes the Sitecore tree, XPath builder or search function are just not the easiest tools to research a particular problem. Once you understand the database schema of Sitecore (which is not that difficult), querying the databases directly can be of great help.

Here is a script that creates 2 handy functions that you can use to make querying Sitecore data just a little easier:

After running this script (be sure to change the statement in line 1 to match your database name), you can write queries such as this one:

This results in:

Screenshot of the result of the previous query

Since the SC_GetPath function uses recursion, make sure your query does not go out of control. SQL Server does not allow too many recursions by default.

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!

UA-4216957-1