Introduction to Engineering

I'd like to discuss a development practice that should, ideally, be ingrained in all software developers (but sometimes, for various reasons is not)

I don't open with this assertion to divide opinion or stir controversy, in fact I've honestly never spoken to a developer that has argued this practice isn't important. Of course, I'm talking about testing.

One of the most common excuses I've heard (and, truth be told, in the past used) is that writing tests takes too long. While writing tests can be time consuming, teams should be aware of the potential time savings to be made over the life of the project.

Our framework of choice, Laravel, makes creating and running two particular types of automated test easy: Unit tests and Feature tests (often called integration tests). Unit tests are used to test small portions of code in isolation, usually just a single method. Feature (integration tests) check that various portions of the system work together correctly. For example, you might check that you can get a particular product, make some changes, save that product and pull it back out with the changes in place.

Let's say, using the example above, we've got a really good integration test that passes. A developer comes along and makes a change to the portion of code that persists our database entity, and now, a field that we change in our test no longer gets updated. The test will run and fail because we would likely be checking the input we're sending, doing the persist and then re-pulling the entity from the database, comparing the values to what we sent. If we didn't have the test in place, the changes might have made it through our peer review process (something that I'll cover in a future post), and then into production. At that point, all bets are off.

Don't get me wrong, automated tests are not a magic solution to every problem, they're only useful if they're well considered and cover all of the important parts of your system.

Testing can also be an integral part of your development strategy rather than something bolted on at the end. Some teams leverage a methodology called Test Driven Development which is where tests are written from specifications, before any code is created. The test will, of course, fail at this point and code is then written to ensure that the test passes. This type of approach requires well written specifications as the tests need to be well considered and concise.

I've only scratched the surface of the world of software testing; there is a wealth of information available on the internet regarding testing methodologies, approaches and tools so I would encourage any one involved in software development of any kind to seek it out. From there, have conversations with team members to establish if you really can afford not to test your code.