I had an interesting discussion recently whereby I asserted that changing the constructor signature of a class should necessarily break some of your tests, if your tests are adequate in their coverage. This tweet generated considerable discussion, and one of the takeaways was a discussion about whether or not writing tests for personal pet projects should be a thing.
I think it absolutely should be.
Thursday, April 14th, 2022 @ 8:12 am | Comments (0) | Categories: PHP, Testing
The other day I came across the following code in a project:
class Users
{
public function __construct(PDO $pdo)
{
$this->pdo = $pdo;
}
public function getAllUsers()
{
$stmt = $this->pdo->prepare('SELECT * FROM users');
return $stmt->fetchAll();
}
}
Tuesday, January 16th, 2018 @ 9:00 am | Comment (7) | Categories: PHP, Testing
Green field projects are certainly rare, but they hold a certain appeal over developers. The ability to ignore all the mistakes of the past, and instead focus on new architecture, new ideas and new methodologies is enticing. And yet, every pile of legacy code spaghetti out there was once a green field project, filled with the majestic hopes and dreams of the engineers who worked on it. What happens?
I know many developers who believe that code simply gets worse over time, that technical debt accumulations are inevitable and that bad decisions haunt us forever. But the truth is that code doesn’t rust. And that means that our ability to make changes is directly related to how well we create the code in the first place.
Tuesday, February 3rd, 2015 @ 9:48 am | Comment (2) | Categories: Best Practices, PHP, Testing
Despite what His Majesty, David Heinemeier Hansson may have said, unit testing is by no means dead. And, in fact, system testing is no more a complete testing strategy than 100% test coverage with unit tests. Let me explain.
Test Driven Development (TDD) is a philosophy that asserts testing is so important that the tests should be written first, to emphasize the design of the code. The idea is that by writing a failing test, and then writing code that passes that test, you end up with an overall better architecture.
Wednesday, April 23rd, 2014 @ 8:09 am | Comment (5) | Categories: PHP, Testing, Best Practices
It’s a persistent statement: controllers should have as little code as possible because they’re difficult, nay impossible, to test. Developers should force most of their code into the models instead, where business, validation and other logic can take place. This way, the models are reusable and the code is easily tested in isolation. After all, if the controller can’t be adequately tested, then the controller can’t be expected to contain very much crucial logic. The controller becomes just a data and information traffic cop.
But this is not true. Controllers are no more or less testable than any other kind of code. What’s more, the fact that people believe controllers are largely untestable is an excuse for writing untestable code, not a valid design decision.
Monday, September 23rd, 2013 @ 7:00 am | Comment (3) | Categories: Web Architecture, System Architecture, Zend Framework, PHP, Testing, SOLID
Bad code. Most of us have seen it before. And most of us are aware of concepts like “technical debt” as it relates to software development practices. But what most of us never actually think about are the specific business challenges posed by code that is loaded with technical debt and difficult to maintain.
Refactoring code is often at the bottom of a business’ to-do list. Features, deadlines, goals and moving the project forward are crucial things that businesses are focused on. There’s a good reason for that: customers don’t buy software because it’s easy to maintain, they buy software because it solves their problem. And thus, refactoring doesn’t seem to have inherent business value.
Tuesday, September 17th, 2013 @ 9:00 am | Comments (0) | Categories: PHP, Testing, Clean Code
| « Older Entries |