{"id":83,"date":"2012-03-19T05:58:49","date_gmt":"2012-03-19T05:58:49","guid":{"rendered":"http:\/\/collaboriscom.wpengine.com\/?p=83"},"modified":"2022-01-12T16:41:18","modified_gmt":"2022-01-12T16:41:18","slug":"ui-testing-sharepoint","status":"publish","type":"post","link":"https:\/\/www.collaboris.com\/ui-testing-sharepoint\/","title":{"rendered":"UI Testing SharePoint"},"content":{"rendered":"

UI Testing SharePoint<\/h1>\n

As part of an on-going series of ‘Testing SharePoint<\/strong>‘ we intend to share some of what we have learnt when trying to automate the testing of a SharePoint add-on called DocRead.\u00a0These posts will specifically cover functional and integration testing – not unit testing (which is worth a whole conversation on it’s own).<\/p>\n

To get started, I want to tell a story about how I have come to love Selenium, but\u00a0first a bit of history about who I am. I have used SharePoint seriously since beta 1 of SharePoint 2007 and worked as a developer or architect for organisations such as Collaboris, NHS, Tarmac, BT, Lloyds of London, Lloyds Tsb, Capita, O2 on both versions. I have tried – like lots of other devs – to make unit tests useful and still get the product out on time. I have done lots of performance testing using visual studio web performance tests in my time and actually quite enjoyed it.<\/p>\n

Having said that, I have never done functional testing apart from to help out here and there. However, as DocRead is really starting to become the success we hoped for I have found myself looking for ways to get new versions out of the door much faster, cheaper and more efficiently! One area that’s been burning our development teams time is testing. It’s all very organized but very manual. We have really good test coverage, but to run though one set of tests for one version takes 4-5 days.\u00a0If you think that DocRead ships on SharePoint 2007 (32 and 64) and SharePoint 2010 that’s 15 man days to get a version out! This also assumes that we only have to go through the test cycle once – which never happens. There are always a few iterations of re-testing for either all or part of your applicaiton.<\/p>\n

Note. for those of you that don’t know –\u00a0<\/em>DocRead<\/em><\/a>\u00a0is an add-on for SharePoint that allows you to require or recommend that groups of users read a document by a deadline. It has it’s own databases, reporting application, web parts, application pages and features to activate at all levels in SharePoint. It solves a simple problem, but actually requires a very robust solution and has tons of different test scenarios to cater for.<\/em><\/p>\n

When trying to help the testers come up with an automated solution, my first reaction was to dive in and use Visual Studio Web Tests, but I soon realized that they weren’t going to fulfill our needs. DocRead uses tons of client side code and Ajax calls to make the experience as responsive and smooth as possible.\u00a0We needed an approach beyond ‘record and play’ that worked at the browser level, not at the http level like web tests do. Enter Selenium.<\/p>\n

Firstly, I can honestly say that I have never touched Selenium until\u00a03 weeks ago. I knew a couple of testers that had and only 1 that had used it seriously with SharePoint. In fact, if you Google ‘Selenium and SharePoint’ you very quickly run out of decent results. Why is this ?\u00a0Let’s think about it. For a tester to automate SharePoint testing they need to know…<\/p>\n

    \n
  1. SharePoint<\/strong> – this in itself is huge!<\/li>\n
  2. How to code<\/strong> – testing has to be automated in some language.<\/li>\n
  3. How to test<\/strong> – testing is a real skill, knowing how to structure your tests is very important.<\/li>\n
  4. A testing Framework\/Tool <\/strong>– Selenium, Visual Studio Test, etc.<\/li>\n<\/ol>\n

    That’s one hefty skillset – finding testers with these skills is very tough!\u00a0 In my opinion, testers also get a rough deal. Developers only consider them when they have time, usually as the first bugs come in. Developers don’t write code that easy to test, (e.g. nice use of CSS, ID’s). And all too often with SharePoint, releases are late due to deployment headaches.<\/p>\n

    The following sections offer some guidance and help explain the problems we had to tackle along the way – (as I write them I will link them!)<\/p>\n