Matthias Noback has posted another article covering domain-driven development practices, this time focusing on testing actual behavior and some of the downsides that can come with it and domain-driven development.

He breaks the article up into three main sections:

• The downsides of starting with the domain model
• The downsides of starting with the smallest bricks
• The downsides of your test suite as the major client of your production code

Each includes a description of the downsides related to the topic and, where it helps, code to illustrate the issue. The post also includes three experiments to try to help prevent some of these downfalls from happening (including not testing constructors and not adding getters).

Tests are not the main use case of an object, they should guide the development process and make sure you write exactly the code that you need. This means not sacrificing the object's encapsulation just to make it testable.

While his examples may be in Javascript, Jani Hartikainen has posted a guide that can help any developer get started with TDD - Test Driven Development - in their new or legacy applications.

What’s the hardest thing in test-driven development or unit testing in general? Writing tests! The syntax or the tools aren’t the problem – you can learn those enough to get started in 15 minutes. The problem is how to take some vague idea in your head about what you want to do, and turn it into something that verifies some function works… before you even wrote the damn thing!

People tell you to use TDD. But how can you possibly write a test for something that doesn’t exist? I don’t even know what the function is going to do yet – or if I actually want two functions instead of one – and instead you want me to think of a test for it? Are you crazy?

How do all those people who tell you to use TDD do it? That’s the thing – test-driven development requires thinking of your code in a different way. And nobody ever tells you how to do that. Until now.

He then breaks down the process of how to turn a "vague idea" into something that can be effectively tested, noting that this change in thought process can sometimes be difficult. He then breaks it down into a set of five steps:

• Step 1: Decide the inputs and outputs
• Step 2: Choose function signature
• Step 3: Decide on one tiny aspect of the functionality
• Step 4: Implement test
• Step 5: Implement code

While the above may seem familiar to anyone that's read about TDD before, it's interesting to see how he explains each item with an emphasis on behavior not just the code required. He ends the post with a few more smaller suggestions to help you get on the road to TDD with the same emphasis on behavior rather than functionality.

Derick Rethans has posted the next part of his series looking at the new an improved MongoDB drivers for PHP in this post to his site. This time he focuses on the updates to cursor behavior from the previous versions.

We released a new version of the MongoDB driver for PHP (the mongodb extension) near the end of last year. In a previous blog post, I covered the back story of the how and why we undertook this effort. And in another post, I spoke about the architecture of the new driver. In this episode I will discuss changes in cursor behaviour.

I recently found the following comment added to the driver's documentation, on PHP.net, which read: "I noticed that ->sort is missing from the cursor. Seems like the old driver has more functionality."

The new driver certainly allows for sorting of results of queries, but no longer by calling the sort() method on the cursor object. This is because cursors are now created differently than in the old mongo extension.

He starts by talking about how the legacy driver handled its cursor functionality and when it actually performed the data lookup (hint: not until used). In the newer drivers the cursor request is made when the object is created. Because of this change, actions like "sort" and "skip" have to be sent as options on the query instead.

The Master Zend Framework site has posted the second part of their tutorial series showing how to test Zend Framework applications with CodeCeption, a tool allowing for behavior-driven testing methods on PHP applications. In part two of the series they finish up the examples from part one and put them to use.

In part one of this series on testing Zend Framework applications with Codeception, we covered what Codeception is, how to install and configure it, and how to enable and configure the Zend Framework 2 module; finishing up by writing some basic acceptance and functional tests. [...] Here, in part two of the series we see how to retrieve and test registered services using BDD-style testing. This isn't going to be an exhaustive look at every possibility of what's available. Instead, what I'm going to do is show a simple set of examples which use two extra modules which come with Codeception and how they enable descriptive, BDD-style, tests.

The tutorial starts by getting into a bit more detail on what BDD-style testing is and some of the basic terminology. They help you install two modules to help make writing your tests simpler. The tutorial walks you through generating a new test for a fictional "Video" table gateway class and how to flesh it out to pull the service from the service manager, configure the database connection and write a few checks to verify the type of the service fetched and the number of records it returns.

NetTuts.com has posted the next part of their "Programming with Yii2" tutorial series today. This new tutorial in the series focuses on the use of the timestamp behavior to assign the current date to an object (like for create or update dates).

In this tutorial, we'll explore Timestamp Behaviors, which reduce the amount of code you need to write with each new model for the common operation of creating timestamps for inserts and updates. We'll also dive into the Yii2 source code, examining how a behavior is implemented.

He starts with a brief look at what behaviors are (a reminder for those that may have already read about the sluggable and blameable behaviors). He then gets into the Timestamp behavior specifically and how to apply it to the sample project's "Status" instances. He shows the updates needed for the behavior configuration and rules. He also looks inside the component at the code that makes it up and the "touch" method it provides.

Mathias Verraes has a new post to his site today with an interesting idea when it comes to handling the architecture of an application: using objects as the contracts for behavior. He suggests that the objects themselves define how other pieces of code should interact with them, not necessarily external services. He illustrates with an invoice and appointment example.

Of course invoices do not pay themselves, but that’s not what an object model is trying to do. An invoice exposes the behaviour of being able to be paid. That ability is in fact essential to what it means to be an invoice. The behaviour is an inherent property of an invoice. If an invoice doesn’t have the ability of being paid, there’s no point in issuing invoices at all. In other words, the contract of an invoice object declares that its interface includes payment as a feature. Its promise to the outside world is that it allows an outsider to pay for it. Encapsulation of state and behaviour is the core idea behind objects.

He wonders why, if this is more true to the "object-oriented programming" ideals, the idea of encapsulating procedural code as objects is so widespread. He suggests a lack of education on the subject or maybe even confusion from spoken languages themselves.

On the Inviqua techPortal today Marcello Duarte lists out his top ten favorite limitations with the PhpSpec testing tool. PhpSpec is a tool where the tests are driven by specifications, focusing on the "how".

PhpSpec is enjoying a growth in popularity lately, probably related to the recent release of 2.0. Lots of people have been playing with it and trying to get to grips with what it can do. Naturally they try to do the same things they would with other testing tools. Soon they find out they can’t. “Oh! This PhpSpec has some many limitations… I can’t do this… I can’t do that…”. Ironically, other people make positive comments about the same “limitations”. So I decided to publish a list of my top ten favourite limitations of PhpSpec, and why I love them so much.

His limitations list includes things like:

• I can't test private methods
• You can’t have code coverage
• I can’t use a data provider
• My tests can’t follow a code standard

Check out the full article for more of his list and some code examples ot help clarify each topic.

Paul Jones has a new post to his site today talking about the importance of naming when it comes to the use of different patterns in development. He also makes some recommendations to help clear up some of the confusion around different names for the same things.

[Thoughts in a] Grumpy Programmer mailing-list essay got me thinking. [...] I completely agree with the emphasis on using a common vocabulary. One issue here is that naming things properly is very, very hard. It is one of the only two hard problems in programming. Are there any rules (even rules-of-thumb) that can we use to make it easier to pick good names for the classes and concepts in our projects?

He reminds readers that code is no place for a "novel context", that is that it's not meant to be instructions for humans, but instructions for computers. He points out that patterns are more about behavior than the name you give them and that picking a name that's "close enough" isn't a good idea. He also recommends that you avoid picking a name for a special context the code might be involved in.

In this new post to his site Cal Evans shares an interesting and seldom mentioned part of the SPL in PHP, the CachingIterator, and an interesting behavior he found with its use.

In the course of writing my next book, “Iterating PHP Iterators”, I found something very interesting. I have a short chapter on the CachingIterator. One of the flags in the CachingIterator is FULL_CACHE. It was during my experiments with that, that I found…an anomaly.

He includes a snippet of code showing the behavior that does work, just not exactly as expected. He found that to have the values correctly cached, he had to loop through the entire iterator before trying to use it. He also answers the "just rewind() the iterator" comments with another code snippet showing it with the same behavior as before. His final example is one that does work as expected, unsetting the correct index and replacing the value as requested.

So today I learned, don’t use the FULL_CACHE flag on the CachingIterator. I am not sure what the FULL_CACHE flag is supposed to do, but it doesn’t seem to do anything useful at the moment. Also, it can screw things up for you.

In a previous post Anthony Ferrara looked at design patterns and their use (and usefulness) in modern applications. in this new post he continues the series but focuses more on a strategy to move past them related to inheritance.

In my last post, I talked about revisiting the concept of Design Patterns and questioned how useful it is to "learn" them. The conclusion that I came to was that you are better served by focusing on how objects communicate rather than traditional patterns. Well, that's not the only "traditional concept" that I think we should move beyond. So, let's talk about inheritance...

He starts with a bit of definition about what inheritance actually is (for a little context) related to classes, not traits or interfaces. He compares two ideas around this inheritance - the actual implementation of it in the code and the specification of it, the planning a "promise" the structure defines. He discusses the separation of these two ideas and that what matters is that the specification is implemented - how doesn't matter as much. He gets down to the most basic concept behind the idea of inheritance, the idea of a "contract", that defines the "agreement" the implementation puts into practice.

Finally, he gets down to what he calls "the key" behind inheritance and encapsulation of functionality into desecrate parts - behaviors. These allow you to know what kind of functionality comes from which class/object without having to guess. Methods have behaviors and objects are collections of these, combining to make a larger object-centric behavior.

Object Oriented Programming is all about abstraction. Each layer is an abstraction of code below it. Using "types" makes this difficult, because often we don't have real-world analogs to represent each layer. After all, an abstraction is specifically not a type. It's the concept behind it. With behaviors, this comes naturally.