I think around 2015, there was a big splash of good training online for PHP. Frameworks upgraded/changed, helped programmers write better code faster earlier than that. Before that, it was a lot of RTFM. So, before, in the earlier days (maybe somewhat still today), I think PHP developers did this:
Often times, I find myself targeting a single file with PHPUnit by specifying the file after the binary in the command line:
The other day, an acquaintance of mine was complaining about never getting ahead in their career. I didn’t really feel like I knew enough about their area of expertise to give any advice - until I heard what they did when they got home. During our conversation, they described their favorite TV shows, how involved they were with the outcomes; basically once they got home, 4 to 5 hours were spent on the couch watching TV.
Answer this question real quick: What was the most impressive thing you did 2 years ago at work? Did you get the proper accolades for it? Or, possibly more important, did you get a performance-based wage increase or some other reward?
It’s important to unit test your application code - even your console commands. So many times, I’ve seen people using the Artisan facade inside of console commands to either queue up new commands or call a different command. This makes it more difficult to unit test the application - you have to rely more on fakery (requiring you to reset your application each time then) and/or integration tests.
I’ve been in the position to hire a lot of programmers over the last few years. This is a great responsibility; one that doesn’t come without a bunch of unique situations, especially when it deals with colleagues and friends.
As a PHP programmer, I struggle to understand the reason for private methods and properties. Now, don’t get me wrong, I know the official explanation for them: “Use this to hide properties and methods from child classes” - but why? There have been a number of times when I’ve done stuff that is way more of a cluster-fnck because of private methods that I couldn’t slightly modify.
From time to time, I get thrown onto a project that has many, many errors in the unit tests. It can be hard to try to figure out what to fix first with so many errors on the screen. Sadly, I’ve had my scroll-back buffer filled many times.
Just another case of RTFM I’m sure, but I was wondering how to preview the changes that will happen if I do a composer update on my current project. I wanted to get an idea of how many libraries would change so I could see if it would be a short or long project (potentially) to do a 3rd Party Library update. (I already hear you - and I agree - the number of files changing isn’t always indicative of how long the task to update your project’s dependencies will take. Shhh - quiet you.)
When you’re testing inside of your PHPUnit test methods, you will use many assert-based methods. Two that are seemingly very similar are assertSame() and assertEqual()