Then I google stumbled across Slim 4.
Not sure how this slipped past me but Slim 3 apparently underwent a major version upgrade to Slim 4 in August 2019.
Luckily, I haven't written much actual code yet so I won't need to re-work all that much.
Rhetorical question, that was.
The php-common library has largely (not going to update the code for AMQP or Syfmony Console until I know for sure I need to use it) been updated with PHP 7.4 bells and whistles.
The unit tests are updated as well and they're all passing except for the handful that are skipped.
I'm not going to do much more to update the unit test code until I'm ready to tackle the upgrade to PHPUnit 9 (or 10 depending on when I do the upgrade) until I get some other things done first.
So, starting tomorrow I'll be diving back into working on mabel . . . itself . . . herself?
I'm not going to lie. Writing and/or updating unit tests can be incredibly tedious. It's a chore I don't love, but it's a chore that must be done.
The updates I referenced in my prior post have taken on that aspect where you feel like you're unweaving a bunch of code so that you can weave it back together again in a better form. It's a little scary at first because you find yourself wondering "Can I put this mess back together in a reasonable amount of time?"
Basically, the refactor I did to remove the "passthrough" connection class meant that I had to change the constructor of the fairly heavily used "AbstractActiveRecord" class if I wanted the code to continue to enforce the concept of dependency injection. That change has rippled throughout the code and resulted in a lot of unit tests needing to be updated.
And honestly? This is EXACTLY WHY YOU WRITE UNIT TESTS. So that when you make changes to your code in one place you know exactly where those changes require subsequent updates to other code. I just wish it weren't so . . . messy.
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.
In my head, Slim 3 is super shiny and new. In reality, it's been around since at least 2015. I find this ironic and I wonder if there's something more modern out there.
Anyhow, it seems to be working well enough. I had a bit of trouble figuring out how to setup the routing correctly so that I could define my controller actions as methods inside classes, but ultimately I found a helpful blog post that put me on the right path. Same goes for correctly using the dependency injection container.
So yeah, I'm going to switch to Slim 3. My 100% scientific reasons?
In reference to the post from December 10th, I've come to the following conclusions.
In that vein, I am looking at Slim 3 as a replacement for Silex.
