Day 7: Run Your Tests Early And Often

In the first principle, we discussed the importance of having tests in order to validate your code and prevent bugs. In this principle, we explore how to apply those tests on a regular basis through continuous integration. Principle seven is modern applications must use continuous integration.

It might seem obvious and self-explanatory that modern applications use continuous integration. After all, building your project after each commit is the simplest way to run the tests and verify the application. But there are thousands of development shops that lack tests, continuous integration, or both. Why? Most of the time because it’s “too hard to set up” or “too expensive to run.” Neither is a good excuse, and both can be debunked.

Continuous integration can be relatively simple to set up. With GitHub releasing GitHub Actions, continuous integration and running your tests on every commit has never been easier. If you’re not using GitHub but using something like GitLab, you can use their built-in tools as well. And if you’re old school, Jenkins is a better-than-nothing solution you can set up and host on premises for your own purposes.

In terms of cost, there is often a cost associated with running continuous integration. However, this cost is minimal compared to the cost of releasing bugs into production or a broken component making it past QA because nobody ran the tests. It’s best to consider it part of the cost of doing business and accept the cost.

I want to make an important distinction here: continuous integration is not the same thing as continuous deployment. A successful application build does not need to be deployed to production to follow this principle; in fact, you can still have any release cycle you like. Some companies choose to release every build. Others choose to release one a week or every other day. Our sixth principle (yesterday) stated that applications should be deployed often, but deployment cadence is entirely up to you. What’s important is that you consistently build your application so that the tests are run and bugs are discovered early, and often.

Thursday, December 31st, 2020 @ 9:00 am | Comments (0) | Categories: Deployment, Testing

Day 5: Debug Code Without Running It

In the old days, PHP applications were written in a loop: make a change, hit refresh in the browser, manually test, find a bug, fix the bug, and repeat. Thankfully, there’s been a tremendous evolution in PHP over the past decade, and we have quality assurance tools like PHPUnit. But in the last few years we’ve gained quality tooling that some thought would never be possible: static analysis. Which brings us to our fifth point: modern applications should use tools like static analysis for quality assurance.

PHP 7 brought about a component in PHP known as the abstract syntax tree (AST). The AST is basically a tree of all the commands in your code, that PHP uses to tokenize and execute your application. When exposed to the outside world, it can be examined, and evaluated, for errors in the code. This is effectively what static code analyzers like Psalm and PHPStan do – evaluate the code for errors.

The types of errors that can be detected are numerous, but are mainly focused on type errors, logic errors and other similar types of errors. The benefits are numerous: you can quickly identify potential and actual bugs in your code, no matter how old or legacy the code base, in an instant.

The first time you run one of these tools against your code you’re liable to receive a significant amount of feedback. Don’t fret; this is normal. Especially if your project is legacy, there’s a good chance there are plenty of bugs that haven’t been found yet, especially if you lack tests. But knowledge is power; once you know, you can go about fixing the bugs you encounter.

You can check out PHPStan at and Psalm at

Tuesday, December 29th, 2020 @ 9:00 am | Comments (0) | Categories: Testing

Day 1: Testing And The Modern Application

The first principle that a modern application must follow relates to testing. Specifically, how well the application is tested, today. This principle is simple, and stated as:

Modern applications must be well-tested.

It is not merely enough that an application be testable, but a modern application should be well-tested. There is a world of difference between the two: the first assumes that an application could, if the developer wanted, write tests. The latter assumes that the tests have been written and are in practice as a component of the application. This is ultimately the goal we are seeking with a modern application.

That’s not to say an application cannot be on the path to modernization if it lacks tests; however, it is impossible for an application to be truly modern without them. Applications must be simple to maintain and easy to change in order to be truly modern, two things that are impossible without an adequate test suite.

Note that I have not specified what kinds of tests are required here. I have not said you must have unit tests, or functional tests, or acceptance tests. Indeed, it is up to the developer, the business, and the team to determine the right balance of tests, the right coverage amounts, and the proper distribution of resources to provide for a test plan. This leaves the measure somewhat subjective, but it always was: code coverage has always been a poor metric of code and test quality.

A modern application must be well-tested. It is the only way the application can be sure to mature and change over time, without stress, without bugs, and without failure.

Friday, December 25th, 2020 @ 9:00 am | Comment (1) | Categories: Testing

Copyright © 2024 by Brandon Savage. All rights reserved.