Don’t write useless unit tests

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();
    }
}

Continue reading

The best way to improve team productivity

3488602921_23bfc81181_oGreen 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.

Continue reading

Unit testing is dead? Hardly.

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.

Continue reading

The myth of the untestable controller

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.

Continue reading

The hidden costs of bad code

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.

Continue reading

Making Your App Infintely More Testable

You’re writing a PHP application. You know you need to write tests. Tests aren’t something that comes naturally to you yet; you’re still working on learning the ins and outs of PHPUnit (the default standard framework). But you know that right now, your app isn’t testable. What can you do to make it testable?

The single most important thing you can do to make your app testable

Continue reading