In a new post to his site Robert Basic shows how to make use of traits to create test doubles in your unit testing practice. He sees them as a simple method for keeping tests clean and not having mocks/fakes/etc. all over.

Keeping your application or library code well organized, easy to follow, and read is important. Your test code should not be exempt from those rules, you should follow good testing conventions.

One part of my tests that I feel like that are out of control are the test doubles. Dummies, fakes, mocks… Seems like they are everywhere and that I keep writing the same ones over and over again. I do follow some good practices on how to reduce code duplication in my tests, but these mocks… Ugh.

He starts with a simple example, showing a test that evaluates the result of a transaction being executed (true or false). However, he describes the eventual "creep" of the tests as more are added and, with each, more "transaction" object instances are required. He suggests refactoring the creation of those doubles into traits where the class they're called from can inherit them and test setup is a bit cleaner. He proposes a "trait for every double" so that they can be easily included as needed and without conflict.

The QaFoo site has a new post showing an interesting practice that could be used in your PHPUnit tests to provide additional functionality without the need for complicated inheritance - the use of traits.

As we already wrote that "Code Reuse By Inheritance" has lots of problems and we consider it a code smell. You should always aim to use Dependency Injection, most likely Constructor Injection. But with test cases in PHPUnit we cannot do this because we have no control about how and when our test cases are created. There are a similar problem in other frameworks, like we discussed in "Object Lifecycle Control". We also blogged about traits as a Code Smell, but let me show and explain why they might be fine to use in your test cases.

They provide an example of where the use of traits might be acceptable starting with a simple test case to check the login behavior with an invalid password. This uses an "is a" inheritance relationship with a parent test class with setUp/tearDown method. This refactored a bit to make use of traits to provide common login functionality based on methods in a trait. The post wraps up talking about traits as a "code smell" despite them seemingly making the test code cleaner, mostly that it limits the ability to change functionality by simply changing the associated code.

On the O'Reilly Software Engineering blog there's a post from Gregory Brown sharing what he thinks is the definition of a "proficient programmer" and how it differs from competence.

Do you know what the difference between competence and proficiency is? That sounds like a trick question, because the words seem to mean the same thing. But the subtle distinction between them is critically important.

Competence means having enough experience and knowledge to get stuff done; proficiency involves knowing why you are doing something in a certain way, and how it fits into the big picture. In other words, a proficient practitioner is always a competent practitioner, but the opposite may not be true.

He goes on to talk about the Dreyfus Model of Skill Acquisition and how it relates to the biggest bottleneck he sees for developers: "crossing the divide from competence to proficiency." He defines what it means to be a "competent" programmer first and then one of the things junior developers struggle with - thinking knowledge is enough to make you more competent. He gives a more concrete example of this with the use of the Memento pattern, when to use and - for the competent side - when it breaks down.

He ends the post with some suggestions that can help you if you're wanting to make the jump from "proficient" to "competent" (even if you've been programming for a long time, some good tips here).

In this post to his site James Lewis makes the suggestion that you consider composition over inheritance when it comes to writing your object-oriented PHP. That is, using PHP's traits functionality to compose interfaces with only the functionality needed, not other possibly useless things.

So what does “composition over inheritance” mean? [...] Lets dive into an example written in PHP to help us better understand composition over inheritance. [...] Almost all modern programming languages have a way of dealing with composition, PHP has Traits. Traits where introduced into PHP at version 5.4 and the PHP docs describes traits as a mechanism for code reuse.

He starts with an example of using inheritance to create new "animal" types but points out that this can lead to extra functionality as sometimes your Robocat just doesn't need to eat. He then introduces traits as a way around the issue, creating traits for each piece of functionality and using PHP's use statement to include only the ones needed for that particular kind of object.

In this post to his site Marc Morera talks about traits, namespaces and how they fit together (or don't).

Some projects using PHP 5.4 are actually using Traits. If you don’t know yet what a trait is, there are some interesting links for you. [...] This post is about the usage of "use statements" in Traits.

He starts with an overall picture of what he's trying to accomplish in a contribution to an open source project (with a word of caution). He talks about how you can make traits and classes more "friendly" with a refactoring example of his initial code snippet. In the end, though, he recommends basically avoiding namespaces if possible in traits, reducing headaches that could be caused either by conflicts or missing dependencies.

Ross Tuck has posted a new article to his site today talking about how he uses traits in his applications and where he sees them having the most value.

Recently, a few folks asked about a trait in a new project I wrote. Right around the same time, Rafael Dohms showed me his new talk about complex cognitive processes we don’t notice. Because my brain is a big mushy sack, the two blended together. The result was this post, which tries to capture how I use traits but also how I decide to use them in the first place.

He starts off with a bit of talk about leverage versus abstraction and how the concepts relate to code. He includes a brief example of each and points out that, while each is good, abstraction tends to be more useful. He then applies this back to the world of traits, how they compare to the use of normal static methods and how they have an advantage of encapsulation without oversharing. He suggests that assertions are more fit as static methods and that traits are a better fit in cases where multiple inheritance is needed. He also touches in interfaces in traits and his opinion on when is the best time to use them.

On the Graze.com Tech blog there's a recent post about sharing logic between controllers with the help of traits. He makes use of the traits functionality in PHP to abstract out functionality common to multiple controllers (in his case, common user functionality).

There have been a few times I have come across a situation where I need to share some logic between controllers but it hasn't been as clear cut as abstracting that logic out into a library. I've been pondering the best way to tackle this problem and would like to share my thoughts.

In his example he shows how two different controllers, the Account and Signup controllers, both need to be able to look up an address and perform some simple checks on the results. The logic is duplicated so he first tries to move it out to an abstract controller but notes that it's not the most ideal solution. Next he tries moving the code out into a library but finds issues with separating out the necessary concerns. Finally he moves the logic into a trait (AddAddressTrait) that contains it and allows the direct integration of his "lookupPostalCode" method into the controller without inheritance or other design issues.

On the SitePoint PHP blog there's a recent post showing you how to use traits with Doctrine entities. PHP's traits allow for the inclusion of functionality into a class without having to extend another class or create an object to use it.

Since PHP 5.4.0, PHP supports a pretty way to reuse code called “Traits” – a set of methods that you can include within another class in order not to repeat yourself. You can read more about traits in previously published SitePoint posts: here, here and here. Today, I am going to show you how they can be used with Doctrine ORM in a Symfony Environment.

He shows how to create two basic Doctrine entities, in this case representing "Article" and "Comment" instances. He then creates the trait, a "TimestampableTrait" class that abstracts out the setting/updating of the create and updated date on the Doctrine record. He refactors the entities to use the trait and shows the results of the "schema create" command.

In his new post Allan MacGregor takes a look at a somewhat underused feature of PHP (since 5.4), traits. He talks about how they can help solve multiple inheritance issues and the power they can offer.

Languages like C++ or Python manage this problem by allowing inheritance from multiple classes, Ruby in the other hand uses Mixings to address this issue. Regardless of the technique the problem remains the same; Traits are another approach to this problem and are commonly used in the languages like Perl and Scala.

He includes an example of the standard PHP method for inheritance in classes via the normal "extends" handling. He refactors this into a setup using traits to "override" the single inheritance issues via a "Cat" trait included in the "Tiger" class providing the "roar" method inside the class context.

The best part about traits is that it makes sense from a structural point of view. [...] Traits are an incredible addition to the PHP language and we have only started to touch the surface.

For those that might have heard of traits (made available in newer versions of PHP, 5.4+) but haven't seen much of a practical application, this new post from Matthew Setter could help.

Here’s the situation which prompted the use of them, in a nutshell. I had a custom view helper which performed some rather elementary date & time formatting, based purely on US standards. When I first wrote the ViewHelper, I wasn’t aware of any other use case I’d have for it. So it made sense for it to be self-contained. Such is life however, as later in development the need did arise to do more date/time formatting. But this time, far removed from the view layer in a model. [...] So I weighed up my options and chose to go with Traits. I’ll be honest, there was the new & cool factor to them as well – as well as an irresistible sense of simplicity in them.

He shares the actual trait code he implemented, making two simple methods - one for formatting date and another for formatting the time - for his views to use. He also includes examples of it in use. He also sought some feedback