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.
I started to actually work on the authorization service (which I have decided to name Mabel) and quickly discovered to my shock and horror that silex/silex has been abandoned. Basically, this is the routing framework that I'm used to using and I wasn't expecting to have to change.
The suggested replacement is symfony/flex. To be honest I'm not exactly sure what symfony/flex even is. It guess it's some sort of code generator that allows you to create the skeleton of a Symfony project by executing a series of commands from the command line. I guess it also handles setting up the routing to your controllers the same way. I'm probably not doing it any justice in my 'description' but that was my takeaway from the documentation/marketing materials on the Symfony site.
It's a personal failing of mine that I'm too resistant to change. I'm deeply skeptical of any new technology until I get to a point where I feel like I understand whatever it's trying to be or do. Knowing that, I set my discomfort aside and decided to keep an open mind and try out this symfony/flex thing as potentially the new way forward.
Only I can't. I can't really install it. There's some sort of weird conflict happening because I'm attempting to use a combination of VirtualBox 6.1, Vagrant, PHP 7.4 and Symfony 5.
I'm not really sure what to do. Should I:
When I left off in early November, I had largely gotten my development environment up and running. That meant it was time to start delving back into the code. The first thing I'm going to write for Robot Fortress is an authorization and user data service. After all, this is going to be an online multiplayer game and to do that I'm going to need to expose a bunch of service endpoints to the brutal chaos that is the modern internet.
I've got quite a lot of experience writing these kinds of services using a Linux/Nginx/MySQL/PHP stack, so it's also a nice place to start and get my head properly back into 'coding space.' Writing the client in Unity is going to be the real stretch (though I do know C#) so I want to start with something more familiar.
As it happens, I have a php library that contains a number of useful classes that will make writing this service a bit easier. However, it is out of date in the following ways:
So here's what I did:
In the end, 854 tests are passing and 3 are currently skipped. The 3 that are skipped are from tests that appear to be failing due to changes in how objects are mocked in PHPUnit. Since I'm going to have update the entire library to be compatible with a 2 major version upgrade to PHPUnit, I decided to defer fixing those tests until that time comes.
I can't even imagine how difficult this would have been if the library had not come in with a high level of unit test coverage.
THIS IS WHY WE UNIT TEST.
THIS IS WHY WE USE DEPENDENCY INJECTION.
Like it's some sort of heavy weight and I have to remember to bend from the knees, not the back.
But seriously, sometimes life just happens and things fall by the wayside.
Anyhow, for all of you who are avidly following this blog (Hah hah hah. Maybe I should start tweeting?) I'm starting to work on Robot Fortress again.
