OData, the specification that did not want to be verified
Written by Bjørn Einar Bjartnes
I have tried and failed to verify OData implementations. This is my short summary of the process.
I am a big fan of verifyable specifications. I want to be able to present my users with a contract, and I also want to some degree be able to verify that I do obey that contract. I have written a blog post on the topic of programming to an interface.
Now, OData implementations, those are hard. I have tried to find a way to verify that they are implemented correctly according to the specification. However, it turns out to be really hard, as the specification is large. Especially when it comes to verify the EDMX files - either if I wrote them by hand (Yes, I have...), generated them myself (Which I do, in some cases in production) or have relied on the OData Nuget packages. The only way I have found that reliable tells me if an OData endpoint works as intented is to actually try it using an OData client. Which OData Client, you might ask? The only one I have found that actually works - and is the client I guess is normally used in practice, is the one used in Excel and PowerBI - the PowerQuery engine.
Now, why don't I simply embed that PowerQuery engine in my tests, you might ask? Turns out, that is against the EULA.
https://github.com/gsimardnet/PowerQueryNet/issues/3#issuecomment-1057409639
So, what did I do? The only thing I have been able to do is to use Excel Interop to remote control an Excel workbook to clear its data and refresh data sources... Then I can read the result back from Excel interop. Which requires actually having Excel installed on the machine running tests.
Yeah, I have tried different open sources OData clients. They were not able to read my OData endpoints, even though they were according to the specifications. Why? Because the specification is too complex.
Great.