This blog contains reflections and thoughts on my work as a software engineer

mandag den 15. oktober 2012

Announcing T.REST – a testing framework for REST ressources

I’ve finally done it – made my debut in the OSS community. As of today my company I have released a bunch of refactored helper classes from a former project as a Codeplex project. The baby have been named T.REST and is a testing framework suited for regression-testing REST ressources. We I developed it as part of a migration process from homegrown backend systems to CRM 2011 and it has evolved to be interesting enough that people outside my company have been curious about our testing abilities regarding REST so the decision for my company to release our testing framework as a OSS project was really a no-brainer.

The case is simple: Imagine that you depend on a REST ressource serving i.e. locations to your Google map. You really want to be sure that the look and feel of the service does not change because your clientside Javascript consuming the service is extremely hard to write tests against and you know for sure that you probably won’t be reading the newsletter email with the paragraph “By the way, service XYZ will introduce breaking changes in the following release” placed somewhere in the middle of lots of other boring stuff

The project will probably evolve over time but the essence of the framework can be expressed in a few lines of code:

[TestInitialize]
public void TestInitialize()
{
RessourceFactory.Init(Assert.Fail, Assert.AreEqual, Assert.AreNotEqual, Assert.AreEqual, Assert.AreNotEqual);
}

[TestMethod]
public void JqueryUIDemo()
{
var expected = new Dictionary<string, Type>
{
{"latitude", typeof (decimal)},
{"longitude", typeof (decimal)},
{"title", typeof(string)},
{"content", typeof(string)}
};

var res = RessourceFactory.Create(new RestConfiguration
{
Url = "/svn/trunk/demos/json/demo.json",
Host = "jquery-ui-map.googlecode.com",
ExpectedObjectSignature = expected,
ExpectArrayResult = true
});
res.ValidateSignature();
}


This lines of code will assert the following:




  • That the REST ressource returns an object with properties


  • That the number of properties matches the number of properties in the expected result


  • That no properties were found which were not specified in the expected result


  • That the types of the properties returned by the REST ressource matches your expected result



T.REST is released under the MIT license so feel free to use in any way you desire.



There are a number of quirks in the original implementation which I have tried to refactor out in this initial release but if you give it a try and stumble upon something please use the Codeplex Issue tracker. If time allows it I would like to write some more code examples uncovering the small quirks and how-to-do’s using the framework so keep an eye on my blog and on the documentation on the Codeplex project for updates.



Regards K.