0

The goal here is to get some WCF Data Services query scenarios accurately reflected in code under test.

Following the same pattern for mocking EF functionality detailed here, I'm mocking a DataServiceQuery wrapper class and delegating to the IQueryable returned by calling .AsQueryable() on my test data.

I want to override the LINQ to objects behavior for a specific equality expression (if it matters, when comparing two byte arrays). I want to compare the values in the arrays instead of the references (e.g. using SequenceEqual).

The way I can see accomplishing this is to create a provider where I visit the expression, pull out the appropriate values, compose a new expression, and pass that along to the LINQ to objects provider. That's a lot of work. Short of doing this, is there an easier way to get this done or will I have to resort to parsing expressions?

moarboilerplate
  • 1,633
  • 9
  • 23

1 Answers1

1

You can try to create your own extension methods that take a more specific data type. Something along this line :

static IEnumerable<byte[]> Where(this IEnumerable<byte[]> source, Func<byte[], bool> predicate)
{

}
Tibi
  • 1,507
  • 1
  • 9
  • 10
  • I like this answer, but wouldn't that mean these extension methods would have to be referenced in my main app? As it stands, the main app is working, I just want to override behavior in tests. – moarboilerplate Sep 29 '15 at 02:35
  • Yes it would, but why would you want your comparison to behave differently when you test it? What would be the point of testing altogether, if you have different behaviours? – Tibi Sep 29 '15 at 15:29
  • I'm trying to work around the different equals behavior between the query providers where the data services provider serializes the byte array for comparison and the linq to objects provider just compares references. When using the linq to objects provider the comparison returns no results (since i'm comparing one set of test data to mocked data). I have other queries that work just fine with the linq to objects provider (which admittedly has its limitations). I either have to work around this scenario or remove all tests that use the linq to objects provider. – moarboilerplate Sep 29 '15 at 15:51
  • If you are testing a different thing than what you are running I would recommend removing the tests. – Tibi Sep 30 '15 at 15:33