LINQ don’t stink

Recently, I had to write a test case that posed an interesting problem.

The product that I am working, Identity Lifecycle Manager "2" uses the concept of sets. Sets are defined by XPath filter expressions. When a user submits a request to create, read, update or delete a resource, then that resource, as well as associated resources, may transition into or out of any number of sets.

We have a Request type for representing user's requests, and when we determine the set transitions that will result from a request, we add the information about those set transitions to the Request object. Each set transition is represented by a piece of XML that looks roughly like this:

A Request object has a SetTransition property of the ReadOnlyCollection<string> type, with each string in the collection being an XML representation of a set transition. We don't have to reason about the set transitions programmatically any further in our C# code, so it suffices that they are exposed as strings of XML, rather than as strongly-typed objects.

Now, in my test case, I create a Request, dip it into the part of our request processor that figures out the set transitions, and then decide whether it calculated the set transitions correctly. It should be apparent that deciding whether the set transitions were calculated correctly is a matter of querying a .NET collection of strings of XML, to determine whether that XML contains the correct data.

As a general solution for querying data of any sort, LINQ seemed to be the appropriate tool for the job, and that did turn out to be the case. Specifically, it was possible for me to craft my test so that I could ask, in a single statement, whether the transitions of two particular resources into two particular sets was detected: