Normally I feel very comfortable with PHP, but not all is good. There's some things I don't like. One is the lack of real annotations and another one is this rare behaviour with visibility within the OO. Let me explain this a little bit.

The problem came up as a part of a recent refactor where a protected method, when called from an object injected into another class, threw an "access" error that it was called from the wrong context. He reported it as a bug but was reminded of how PHP handles exposure - on the class level, not the instance of a class level.

What does the word UNIT in unit testing stand for? Think of an answer and read on! So? Did you say "A method! Because we test methods!"? If so let me offer another perspective.

He suggests that, rather than about just the methods in the class, it's more about testing the "observable behaviors" of the class. That is, anything that you could publicly use the class for and have something happen. He gives examples of this shift in focus - calling setValue and evaluating the result versus just calling the class property itself (then calling the method). He also includes a bit about testing behaviors - what happens when my script does [this] and how does that effect the overall class.

When your tests fail but the class "still works" and you need to "fix the tests" the your tests are worth a lot less as they don't really give you that cozy safety net that they should provide you with.

Join Boston PHP and O'Reilly Author Chris Shiflett as we take you through a fascinating talk on the human behavior and social aspect of security. We'll explore topics such as change blindness and ambient signifiers, and we'll show some real-world examples that demonstrate the profound impact human behavior can have on security. If your a designer, developer, human interaction designer, you won't want to miss this talk.

So far there's over 150 marked as attending - if you plan on trying to make it tonight, be sure you RSVP so they know how many to expect.

A behavior, as it is called in Yii, is a manner of combining objects at runtime to extend an object's functionality. Behaviors are an excellent way to decouple code and keep ever expanding systems maintainable. [...] We can not reuse our code effectively because PHP doesn't support multiple inheritance. The Yii behavior system is a way of achieving multiple inheritance by implementing mixins.

He gives an example of working with a user that's connecting to your application just to get to a third-party billing system. They show how to take this functionality our of your generic "User" class and make a behavior out of it. This functionality can then be attached to the User object (via an attachBehavior call) and used directly. He gets into how Yii does this magic, showing how it appends it to a special value in the class and the __call method checks the method call to see if it exists in one of these special classes.

For a long time I've held that __get and __set in PHP were not all that hot - mostly because it's solely error handling. There's no way to deal invoke __get or __set behaviour for properties that are defined on a class. [...] For those who insist on using __get/__set, I *typically* see this [messyy] sort of style code. The effect is to cram a bunch of unrelated code in to the __get/__set overloading methods.

He suggests an alternative to the "cram it all in __get" approach - callbacks to other methods in the class to handle the different variable possibilities. In the comments there's other suggestions on how to get the same job done differently - mapping property values with __call, valid uses for getters/setters and a pointer to an internals discussion RFC about this same thing.

Quality assurance (QA) is one of the most difficult things to implement around software development. Most of time it is left for the final phase of development and very often overlooked entirely. As many experienced web development teams already know, QA needs to be part of the development process from the get-go. [...] Behavior development/testing is just one aspect of quality assurance.

They briefly touch on the installation of the plugin (Symfony plugins are usually pretty easy to get set up) and link to the project's homepage for more references on some of the basics of using it to act as a browser, parse the response and use forms on a page.

Pádraic maintains that one assertion per test is a rule that should always be followed unless there is a specific good reason to break it. I prefer it as a guideline, as does Robert C. Martin in the book Clean Code. The reference is not intended as an appeal to authority to "prove" that I'm right. I'm just making the point that I think this reflects the current state of the art, which is not necessarily perfect, of course.

Dagfinn talks about behavior-driven development and illustrates how a two assertions could be combined into one but that the end result "isn't very pretty" - and that's just testing two proterties of a single object. Imagine what would happen if things got more complex.

• Normalizing CakePHP model records
• Lookupable Behavior
• Cloud Behavior
• Akismet Datasource

Check out their PHP and CakePHP category on the blog for more great articles and tips.

Using the new behavior is much like using the script as it was before. You can name the validation properties to include the action name and it'll automatically set that validation set as the default.

His behavior lets you define validation rules, both included in a default set and as callbacks. He includes an example of its use and the full code (all thirty lines of it) for the behavior itself.

In CakePHP you declare what models you're going to use in a controller by defining $uses variable. You can also define it in AppController to have a certain set of models available in every controller. However be careful when doing it because you may put yourself in an unexpected situation as I did recently.

As soon as he made his script include a 'User' model in every quest, his logins stopped working. His script errored with a "Database table sessions for model Session was not found" message and refused to work. Digging deeper, he found that CakePHP merges an AppController's $uses value with the SessionControler's values. One overrides the other and your 'User' gets lost in the shuffle.

Do you have a rational explanation for such behavior? I have none. It's very unintuitive for me.