As developers, a large portion of our time is spent testing code that we’ve just written. In a traditional testing cycle, we’ll write some code and then manually test. We’ll enter some inputs and find that it causes an error so we’ll write a little bit more code to fix that error and test again only to find another set of inputs that fails. We’ll slowly work through this process until we feel confident that everything is operating correctly. But how do we know that the first set of bad data we found is still error-free? How do we know it’s still error-free a year from now?
We could continue to manually test all these permutations but almost all of the time they’re going to continue to run perfectly. Because it’s very time consuming to run through all these permutations we’re not going to keep this up. Using tools like PHPUnit we can create automated tests that will make testing our code infinitely more repeatable. Embracing Test-Driven Development (TDD) will allow us to quickly build a suite of automated tests that will allow us to improve the maintainability and reliability of our code.
Read MoreOne of the hard parts about learning how to develop software is the minefield of acronyms that exist within the industry.
The goal of this series of articles is to shine a light on an acronym so that the next time another developer uses it in conversation you can follow along without missing a beat.
Read MoreIn PHP it’s fairly common to see the if
statement.
We run across these all the time and can easily understand what happens when we pass them a true
or false
value. However what happens when the condition of the if
statement is an object, a string, or a number?
Loosely typed languages like PHP allow us to use any kind of variable as if it was a boolean value in our if
statements.
When PHP needs to evaluate the if
statement it converts our variable into something is can represent as a boolean. Ideally this would be a true
or false
but in PHP it will convert any variable into something it can represent as one of those two values. This is where “truthy” and “falsy” come in. A variable that isn’t true
or false
can be truthy or falsy.
Luckily for us there’s a logical consistency with how PHP type juggles our variables into truthy and falsy. For the most part the logic is that anything “empty” is falsy and anything with a value is truthy.
0
is falsy but 1
or -1
are truthy.
Empty arrays are falsy but arrays with a value are truthy.
Empty strings are falsy but strings with a value are truthy.
null
values are falsy.
By default when Vagrant boots a VM it do so in a mode know as “headless mode”. Headless mode just means that no UI from the underlying provider is displayed. There are going to situations where we’re testing changes to our VM and we’ll be unable to access the VM using vagrant ssh
(such as when we make a mistake altering the firewall rules). In order to display the UI we can add vb.gui = true
to our virtualbox configuration.
Vagrant.configure("2") do |config|
config.vm.box = "generic/ubuntu2004"
config.vm.provider "virtualbox" do |vb|
# Display the VirtualBox GUI when booting the machine
vb.gui = true
end
end
The next time we perform a vagrant up
or vagrant reload
VirtualBox will open and we’ll see the virtualbox displayed.
Then we can login using vagrant as the username and password and preform any actions we need to troubleshoot the problem.
What if I told you PHP has a built-in feature that will reduce the number of bugs in our code base? What if I told you it’s super simple to introduce into your daily coding routine? Would you be interested in using it?
In this article, we discuss why we should always use type declarations for function parameters and return values.
Read MoreThis post is the companion piece to my presentation at Midwest PHP 2021.
Read Moresubscribe via RSS