We've gone from tretton37 to 13|37.

We’re still the same company with the same heart and focus on empowering clients and colleagues – and that will never change – but now we’re shorthand! If you want to get in touch to talk to us about empowering your organisation, uncovering your digital capabilities or find out more about life at 13|37 then head on over to 1337.tech.

tretton37.com will be available for a limited transition period only. Have a wonderful day.

Visit us at 1337.tech

Unit Testing the Forgotten View In SharePoint Web Parts

Posted 2011-03-24 By Tobias Håkansson

A while back ago I had the opportunity to take part in the development of a SharePoint Web Part that should display a plain list of open orders in a SPGridView. My previous experience of SharePoint hadn't exactly been a fairytale and nicknames like SharePain and PainPoint were frequently used in our team. These nicknames are still used from time to time but experience has shown me that by using test-driven development when developing a SharePoint Web Part the implementation can be made rather friction free. But to be honest the deployment process is not my friend and weird things keep surprising me.

After all it was a great experience and we all learned a lot. One thing that I did observe when reading about unit testing SharePoint Web Parts was the lack of testing the View. The recommended approach when unit testing SharePoint Web Parts is to use the Model View Presenter (MVP) pattern, and there are many examples and guides that explain how to do it. But when reading all those examples and guidelines I noticed that they only tested the Presenter in MVP, and not the View. Some would argue that it isn’t necessary to test the View, but in our project we found it equally important to test the View as to test the Presenter, especially concerning the importance of when controls are added in the web part life cycle.

To unit test the View we created a testable web part that inherited from our web part, exposing methods to invoke the different events we were interested in. Below is a limited version of our testable web part, with reduced code and some renaming for easier demonstration.

As we were using the SPGridView we wanted to make sure that the control was added when creating child controls. When invoking the CreateChildControls method we could assert that the grid view was added.

We also created a testable grid view to get hold of the data that was bound to the web part.

The testable web part also enabled us to test for css and javascript registration among other things.

As you can see there was no magic involved when unit testing the View. Our approach gave us a better understanding of how to work with SharePoint Web Part development and for all of you sharing my previous SharePoint experience I hope this can help you give it another shot.

Shameless plug: We are a very unique family of driven software-creating professionals.

Join us. We are hiring in all our offices in 🇸🇪 Sweden & 🇸🇮 Slovenia.