Wednesday, December 16, 2020

When Good Ideas Turn Bad

 In retrospect, maybe it wasn't such a good idea.

I've used doctrine/dbal for years now. I like having a 3rd party library that I can use to interact with a database but I don't want all the complexity and overhead of a full fledged ORM. Besides, I just don't like ORM's all that much. I 'feel' that they lead to coding practices that result in 'bad' SQL.

Anyhow, shortly after we started using DBAL, my dev team at the time also saw the way, the truth and the light when it came to dependency injection. One of the concerns we had at the time though was how to be sure that we were only testing our code and not unintentionally testing the code of any 3rd party libraries that we were using.

For DBAL, our (my since I'm the idjit that did it) solution to this conundrum was to wrap the connection class in our own connection class that acted as a big passthrough. That way, when we were mocking the connection class for a unit test, we were mocking OUR class and not THEIR class.

In retrospect (and now that I'm a lot more comfortable with DI) I'm not really sure why this seemed like a good idea. I suppose it didn't really harm anything, but it really didn't help either. Is there really any difference between mocking a class that lives in our code that's basically just a big passthrough and mocking the code that's being pass through too?

And it turns out that there's one gigantic flaw that won't appear until there's a major version update that fundamentally changes the API of the source class the passthrough is based on. When that happens, your unit tests will continue to pass even though they REALLY REALLY REALLY should not.

So yeah, I am going to have to revisit the approach that the common library I'm using has with respect to DBAL. I am most likely going to do away with the passthrough class entirely as I'm just not seeing all that much difference between mocking a passthrough class and the base class itself. The passthrough has a couple of modifications that enforced team specific practices at the time, so I'll need to revisit those as well and decided if/how they should be preserved.

No comments:

Post a Comment