Freigeben über

SPG Continuous Integration builds not run on instance of SharePoint

  • Artikel

Our Continuous Integration builds are run on a build server that has the necessary SharePoint assemblies, but with no installed instance of SharePoint.

Licensing issues aside, this causes an interesting problem when unit tests are developed on dev boxes that have SharePoint installed. Several services found in the SPG Partner Portal application access SPFarm.Local. Developers often fail to mock out this dependency in unit tests as this property is always available on boxes that have SharePoint installed. These unit tests ran fine on dev boxes, but fail to run on the build server and it took some time to figure out why.

As part of good unit testing, remember to mock out any of your code’s dependent objects that could potentially cause problems with your tests. Here is a simple example of how we use Typemock Isolator to mock the SPFarm.Local property.

 

 SPFarm fakeSPFarm = Isolate.Fake.Instance<SPFarm>();
Isolate.WhenCalled(()=>SPFarm.Local).WillReturn(fakeSPFarm);

//Arrange
//Act
//Assert

Comments

  • Anonymous
    June 24, 2009
    Interesting point.  Do you think there would be a way to scan for these types of errors in the unit tests, and automatically replace them with the mock'd out interface. That way it wouldn't be something that would cause the builds or tests to fail, it would just be automatically handled during the build process.

  • Anonymous
    July 17, 2009
    Hmmm... I'd be worried about the "automatic" behaviour causing strange side effects. Especially for developers new to the team who aren't aware of this functionality.