On the Laravel News site there's a tutorial posted that makes some suggestions about how to anticipate application failures by using effective unit testing.

When you start working on a new feature, it is wise to plan out not only how it is expected to work, but what happens if something fails. Taking the time up front to anticipate failure is a quality of a great developer.

[...] Since we don’t know when a dependency might fail, it’s best to plan for failure by having tests so we can be more confident in failed states. Laravel can help us write tests that plan for failure using real-time facades.

In their example, they create a simple "article" repository class that makes use of a HTTP client to fetch the information for each article (by ID). In this case the client is Guzzle. They then add a singleton to the configuration to fetch the API class and show how to implement it in a controller. With this structure, they then move on to testing for failure via real-time facades and mocking a Guzzle response using a "Client" facade instead of calling it directly.

The SitePoint PHP blog has a new tutorial posted that introduces the idea of "Poka Yoke" - basically defensive programming - and how to apply it in your own development processes.

When working in a medium to large team on the same codebase, it can sometimes become hard to understand each other’s code and how to use it. [...] It can be quite hard to remember how particular classes were intended to work, both on their own and in combination with each other. At that point, it becomes easy to accidentally introduce side effects or bugs without realizing it.

These mistakes might get caught in quality assurance, but there’s a realistic chance they might slip through. And even if they get caught, it can take a lot of time to send the code back and get it fixed. So how can we prevent this? Enter “Poka Yoke”.

The article then introduces the basic ideas of "poka yoke" and the two main parts: mistake prevention and mistake detection. It then gets more practical and suggests some PHP-specific things that can be done to prevent mistakes such as:

• the use of type declarations
• using value objects
• making use of effective validation
• returning null objects

For each there's a brief explaination and some sample code to help make the example more practical.

In a new post to his site Free Litjen talks about defensive programming and the part that sane default handling plays when dealing with exceptions that might pop up.

With over half a million visitors a week and lots of scrapers, bots and other stuff visiting, these exceptions and fatal errors clog up logging quite a bit. Not to the point that we can't handle the volume, but it generates false positives in monitoring channels and it is something we do not want to act upon anyway.

So while I'm happy to see some defensive programming I would be even happier if exceptional situations would be silently resolved to default situations.

The post starts with a quote about defensive programming and how, despite it not being an ideal use, many applications had been seen using exceptions to handle errors and messaging. He proposes another methodology where a set of default values are used instead of just failing on any error hit with the input. The idea has merit but it can also lead to other frustrations like hidden errors in testing and situations where an exception makes more sense than a default.

In this post on Medium.com author Diego Mariani talks about the "Art of Defensive Programming" as it relates to the security of the code developers write.

Why don’t developers write secure code ? We’re not talking yet another time about “clean code” here. We’re talking about something more, on a pure practical perspective, software’s safety and security. Yes, because an insecure software is pretty much useless.

[...] Why do I think Defensive Programming is a good approach to issue these problems in certain kind of projects? [...] I personally believe this approach [of continued functionality even in unforeseen circumstances] to be suitable when you’re dealing with a big, long-lived project where many people are involved. Also for instance, with an open source project that requires a lot of extensive maintenance.

He then covers some of what he sees as key tenets of programming defensively:

• Never trust user input
• Use database abstraction
• Don’t reinvent the wheel
• Don’t trust developers
• Write SOLID code
• Write tests

For each item in the list he provides a brief summary of the idea behind it and, in some places, some example code to help illustrate the point. The examples are in PHP but the principles could be applied to just about any language.

The Full Stack Radio podcast has posted their latest episode, Episode #37, featuring an interview with Chris Hartjes, most well known for his promotion and teaching about writing tests (unit, functional, integration, etc) for your applications.

n this episode, Adam talks to the Grumpy Programmer himself about getting started with testing PHP applications.

Topics include: recommended testing tools, PHPUnit vs. phpspec, Mockery vs. Prophecy, the benefits of defensive programming and how to convince your manager to let you write tests.

They also mention Chris' new book "Minimum Viable Tests" and the Patchwork monkey patching library. You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the episode directly. Be sure to subscribe to their feed or follow them on Twitter for more information as new episodes are released.

The SitePoint PHP blog has posted a tutorial continuing on from some previous advice with even more defensive programming practices you can use in your PHP applications.

Many people argue against defensive programming, but this is often because of the types of methods they have seen espoused by some as defensive programming. Defensive programming should not be viewed as a way to avoid test driven development or as a way to simply compensate for failures and move on. [...] What are these methods, if not ways to anticipate that your program may fail, and either prevent those, or else ways in which to handle those failures appropriately?

They go on to talk about the ideas of "failing fast" when errors happen in your application with an extra suggestion added on - "fail loud" too. The tutorial then looks at four different places where more defensive programming techniques can be applied (and how):

• Input validation
• Preventing Accidental Assignment in Comparisons
• Dealing with Try/Catch and Exceptions
• Transactions

They end with a recommendation that, while you should fail fast and loud when issues come up, be sure it's not to the determent of the overall user experience or sharing messages with users that may just confuse them.

In an article from the SitePoint PHP blog author Jeff Smith walks us through some advice he has about defensive programming in PHP, that is good practices for writing code that more gracefully handles potential error points.

Defensive programming, simply put, is programming with the intent to anticipate likely failure points. The goal is to circumvent those likely problems before they occur. You see the problem, right? There’s something inherently difficult with the advice “expect the unexpected” and it’s made many times worse when one alters it to “expect the unexpected and try to prevent it”. Let’s look at some practical examples.

He touches on a few of the most common places where errors could be introduced with unexpected input or functionality:

• Conditional Statements
• User Input (and trusting it....hint: never)
• Assumptions [Made] About Your Code
• Tunnel Vision (or not using good development practices)
• Consistency in Syntax and Naming

Each point in the list includes a brief summary of what to look out for and things you can do to prevent the problem. It's by no means an exhaustive list, but it is a good place to start.

As anyone who's been developing applications (web or otherwise) knows, there are certain things that you just don't do when you're doing things like adding features or changing the code of a production application. There are some general rules to follow and this new article on the PHPClasses.org website reminds us of just a few.

This article describes software development practices that have been used to prevent problems that can break Web sites.

Included in his list are things like:

• Handle unexpected conditions Test your code
• Monitor your site errors and act upon them
• Do not disclose errors to the users
• Do what you can as you can never get defensive enough

He also recommends two resources for some additional reading - the Wikipedia entry for "defensive programming" and a chapter from Getting Real (from 37 Signals) about how to "Get Defensive".

As anyone who's been developing applications (web or otherwise) knows, there are certain things that you just don't do when you're doing things like adding features or changing the code of a production application. There are some general rules to follow and this new article on the PHPClasses.org website reminds us of just a few.

This article describes software development practices that have been used to prevent problems that can break Web sites.

Included in his list are things like:

• Handle unexpected conditions Test your code
• Monitor your site errors and act upon them
• Do not disclose errors to the users
• Do what you can as you can never get defensive enough

He also recommends two resources for some additional reading - the Wikipedia entry for "defensive programming" and a chapter from Getting Real (from 37 Signals) about how to "Get Defensive".

In his latest blog post today, Ivo Jansch takes a look a t a situation where a little "defensive programming" would have helped.

A few weeks ago, we had a major problem with software we'd written for a client. It was software for sending mailings to the client's customers. Suddenly there were many reports of clients receiving multiple mailings instead of just one.

The problem appeared to be in our test code. The software had a 'test' mode for testing the mailing by sending it only to the author and a small test team. It appeared that for some reason, all test mails were being mailed to the customers as well.

This problem would not have appeared if we had applied what I would like to call 'defensive programming'.

He shows code examples from this situation, pointing out where the issue lies - a bad check in an if() statement.