There are three things in life that are always held to be true: we will die someday; we will pay taxes; and software will have bugs.... LOL [...] A testing strategy is often overlooked in software projects. This should not be too surprising, we want to build applications quickly and release them quickly. However, leaving quality out of the picture or towards the end are terrible mistakes.

He talks some about the different types of testing that revolve around software development - "business facing" and "technology facing." These are each split down even further into things like acceptance, integration and unit testing.

This bring us back to the question whether it's feasible to eliminate duplicated strategy logic via Inheritance rather than switching over to plain Composition. Indeed it is, and the clean up process can be conducted through an ubiquitous pattern known as Template Method. [...] Simply put, there's a base class (usually an abstract one), which declares a concrete method (a.k.a. the template) responsible for outlining the steps or hooks of a certain algorithm. Most of the time the base type provides boilerplate implementation for some of those steps and the remaining ones are delegated to subclasses.

The subtypes then override the base's functionality and extend it with their own. They show an example of this by making a jQuery image slider (using this plugin) , an "AbstractCycleSlider" class and two subclasses for two other types - "FadeSlider" and "ScrollSlider", each outputting their own HTML. It also shows how to implement a slider using a different plugin and output both in the same script.

A project that I'm working on right now required me to migrate data from the existing database to the new database and database structure. Since the application is built on top of Symfony2, I decided to write a Command that would take care of the migration. I ran into an issue though: Doctrine2 insisted on creating new IDs where I wanted to keep the old one. The solution turned out to be really simple.

The actual code for the Command is only a few lines long - it just turns off the "AUTO" strategy for each of your entities, making it ignore any IDs you have set on the entity already.

Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn't have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn't mash the logging level together with the message.

Included in the post is sample code, first showing the initial version of the logging class, complete with accompanying tests. Following that, he shows how to refactor it into something using the Strategy pattern, replacing the logging type switch statement with protected methods for each logging message type (critical, notice, etc).

A common problem that developers face when building applications is how to allow the application to be "plug-able" at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let's look at some patterns and common implementations.

The patterns he covers are:

• Observer
• Mediator
• Strategy
• Decorator
• Chain of Responsibility

For each there's both a bit of sample code showing it in use and links to some examples from various frameworks and other projects.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

The Strategy Pattern is used to decouple an algorithm from the context in which it is used. I'm going to equate this example to a real world scenario starring a man, I'll call him Bob.

In his example Bob heads to work and takes whatever way he wants to get there. His boss only cares that he makes it there, not the path he takes. Bob can take many different ways ("strategies") to get there, but how is up to him. Tom illustrates this with a bit of sample code with a "bob.php" that can use any number of other classes/methods to get to work (like commute, the train or a car).

The list so far includes the patterns for:

• Recoded tests
• Scripted tests
• Data-driven tests
• Test automation frameworks

Keep an eye on this great series. There's more to come that can be quite helpful when you're trying to generate those tests and procedures around them.

If we are starting from absolutely nothing, building tests as we go is a near-trivial process. [...] Unfortunately, most of us don't have this situation. We walk into a project with documentation ranging from non-existent to seemingly-useful-but-really-out-of-date, and hundreds of thousands of lines of code, and the coding standards and practices of every developer that has come before us. In this situations, the above Unit Test example is almost mocking us. We can't start that simply! Or can we?

He walks through some of the steps he and another project lead took to start their trip into testing - finding the most problematic bits of code first (based on bugs in the tracker) and testing them, figuring out how to test rapidly changing code, finding common code used in several places and testing that and

]]> Mon, 25 Oct 2010 08:52:18 -0500 http://www.phpdeveloper.org/news/14934 http://www.phpdeveloper.org/news/14934 In this new post to his blog talks about authentication strategies in Zend Framework applications with the combination of Zend_Acl and Zend_Auth.

I'm going to talk more about ACLs than Auth. Auth is simple, it's the ACL that will trip you up. Since both concepts are coupled together when you're making a login system, I feel it's appropriate to at least touch on Auth. What I want to cover is the ways we can create the ACL object to suit needs based on the scale of the project. I'm going to assume that readers have a passing familiarity with using the Auth and Acl objects and may have even implemented them into projects.

He talks about two things you'd need to consider - scalability (how to define your ACLS: hardcoded, in the navigation object and defined in a database) and working with ACLs in multiple projects.

]]> Tue, 10 Aug 2010 12:20:00 -0500