Jessica Mauerhan has a tutorial posted to her site that covers the five types of test doubles in PHPUnit and how to use them in your tests. Test "doubles" - the most common one being a mock - are useful for simulating resources or other objects required to test units of code without external interactions.

Did you know that a Mock is only one type of a test double? Most of us use the word “mock” to mean any kind of test double, but there’s actually five different types. It really can help you understand what you’re trying to accomplish with your test if you know a little bit more what you’re doing with your test doubles, so this article will explain the kinds of test doubles, when you use them, how you use them and why.

She starts the post with a brief definition of the term "test double" and then covers each of the five with descriptions and example code:

• Dummy
• Stub
• Spy
• Mock
• Fake

While some of the functionality is similar between the types, she defines their differences and the cases where each would be most useful.

In a recently posted tutorial on the TutsPlus.com site, author Sajal Soni gets back to the basics and covers the use of arrays in PHP.

In this post, you'll learn the basics of arrays in PHP. You'll learn how to create an array and how to use associative and multidimensional arrays, and you'll see lots of examples of arrays in action.

The tutorial then starts with a brief introduction to what arrays are and how they're defined. From there it shows:

• how to access array elements
• types of arrays
• some useful array-related functions

Each item (and function example) comes with a code snippet to show it in use as well as a brief summary of what's happening.

In response to a comment he saw on Twitter about comments in code, Matthias Noback has written up a post with some of his own thoughts.

Recently I read a comment on Twitter by Nikola Poša. [...] He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

Matthias starts with the suggestion that, when correctly written, code shouldn't need comments to be clear about what's happening. He encourages the use of the "refactor for clarity" method to remove comments and make the code more clear. He finishes the post by breaking down the types of comments (explanatory, todo and "wtf"), what they are/examples and in what situations they can be useful for.

Ruslan Karimov has written up a post for the 4xxi.com blog covering the use of custom types with Symfony and Doctrine to implement features specific to your database of choice.

ORMs are great. In theory, they insure you against potential changes in your RDBMS and offer an easy plug’n’play solution for integration your domain code with database. In practice, however, since ORMs have to be compatible with all major vendors, their possibilities are often limited. Perks and tricks of specific RDBMS are left out.

One of such perks is so-called range types in PostgreSQL. There are plenty of cases when range types are applicable, but people (in my experience) often stick to old solution with two separate DATETIME columns. Last time I asked a fellow developer about the reason behind it and they said: ‘I use Doctrine in my project, and Doctrine does not support it’. So here we are.

He starts with a brief introduction to a custom type in Doctrine and a ranged type in PostgreSQL. He then shows how to create a custom "DateReangeType" to work with the ranged types and how add it to your Symfony configuration as a custom type. He ends the post with an example of it in use in an entity and in the client code making the database request. Full code can be found in this Github repository.

On thePHP.cc blog today there's a new post sharing some helpful hints related to refactoring your application to PHP 7 written up by a friend of the group, Tim Bezhashvyly.

Recently I have migrated a relatively large codebase from PHP 5.6 to PHP 7 and would like to share some of my learnings. To get the most out of this article, you should be familiar with scalar type declarations (and return type declarations). To learn about these and other features of PHP 7, I recommend the "PHP 7 Explained" eBook.

He makes the recommendation of a bold first step: enabling the strict typing on every file in your application to enforce the typing of all values. Next he recommends running your current test suite to see where the failures are. Changes are pretty high that you'll find issues with type switching and magic method handling. He suggests a method for migrating your code effectively to PHP 7: a test-driven migration. This focus works fine if your coverage is good but unless you're exercising all parts of your codebase things will unfortunately be missed.

He also points out some other changes you can make with this update including the removal of some PHPDoc annotations (you'll know the type for sure now) and modifications that may need to be made to current mock objects in your tests. There's a few other smaller things he recommends looking out for as well including the use of the "silencer" operator and exception changes.

Pascal Martin has made the tenth post in his series covering PHP 7.1 and how it differs from previous versions. While this series was previously mentioned there have been significant updates to the series warranting a new post.

Here is the full list of the current ten articles he's written up so far:

• PHP 7.1: introduction and releases cycle
• PHP 7.1: testing a pre-release
• PHP 7.1: enhancements to errors handling
• PHP 7.1: changes to types
• PHP 7.0: new features from the not-so-distant past
• PHP 7.1: better syntax, a more consistent language
• PHP 7.1: create a Closure from a callable
• PHP 7.1: a few other things
• PHP 7.1: actually… No!
• PHP 7.1: the road towards PHP 7.2 and PHP 8.0
• PHP 7.1: a few bc-breaks and conclusion

There's lots of good information about this upcoming minor release in each of these articles as well as an interesting view into the release process for a new PHP version.

Pascal MARTIN has been in the process of posting a series of articles to his site covering the upcoming PHP 7.1 release including coverage of both new and deprecated features. So far there's four articles post with the latest coming out today:

A new minor version of PHP is just around the corner: PHP 7.1! Its release date is not really set yet, as it depends on the amount of bugs that will be reported and fixed on Releases Candidates, but it should happen before the end of this year. One year after PHP 7.0, this first minor release will bring its fair share of new enhancements!

Let’s take a look at those, going with about ten posts spread over the next few days.

So far he's covered:

• introducing PHP 7.1 and its release cycle
• the methods used for testing a pre-release
• enhancements to error handling
• changes to types

Keep an eye on his site in the upcoming days for more pots in this series, helping you to prepare for the 7.1 release before it happens.

Johannes Schlüter has a post to his site detailing the handling of types in PHP and MySQL and how they might act differently than expected in some situations.

Since PHP 7.0 has been released there's more attention on scalar types. Keeping types for data from within your application is relatively simple. But when talking to external systems, like a database things aren't always as one eventually might initially expect.

He talks about MySQL types and how they relate to the "network protocol" being used, converting everything to strings. He includes a few examples of hinting on the results, one where an integer is expected/string provided and another where a string was type hinted but an integer was returned. He points out that sometimes this is a limitation of what PHP can handle, not always what MySQL returns. He also includes other examples of returning decimals - sometimes as a number value and others as a string.

This leaves the question whether you should disable the emulation in order to get the correct types. Doing this has some impact on performance characteristics: With native prepared statements there will be a client-server round-trip during the prepare and another round-trip for the execute.

On the Laravel News site today they've posted a tutorial helping you learn more about the grant types in the OAuth2 functionality provided by Laravel Passport.

OAuth2 is a security framework that controls access to protected areas of an application, and it’s mainly used to control how different clients consume an API ensuring they have the proper permissions to access the requested resources.

Laravel Passport is a full OAuth2 server implementation; it was built to make it easy to apply authentication over an API for laravel-based web applications.

For those not familiar with some of the terms around OAuth and its handling, they start with a few brief definitions (those that are familiar can skip them). Following this the post gets into the creation of a two kinds of grant handling with Passport: third-party authorizations and first-party applications (your own apps authenticating against the OAuth server). The post ends with a brief mention of creating access tokens manually, but points out that thing functionality should probably only be used during testing.

Matt Trask has put together a new post spotlighting a handy library that's widely used across the PHP ecosystem for generating UUIDs: ramsey/uuid.

Welcome to the first installment in my 2113918230981 part series, "Better know a Package!". Tonight's package: the famous/infamous Uuid package that that taught us all what Ramsey is in Scottish, Rhumsaa. Created to give PHP a library to generate Universal Unique Identifiers, this library has been a stallwort in the community. Ben Ramsey created it first under the Rhumsaa namesapce before moving it to the Ramsey namespace, saving us all from learning more Scottish then we needed to ever learn.

[...] A UUID, or Universally Unique Identifier, will generate a 128 bite unique key in different series based on the version you asked for. RFC-4122 dictates how Uuids should be generated, and recommends 4 types.

Matt then goes on to describe each of the different UUID types and provides some code examples as illustration:

• Version 1: Time and MAC addressed based Uuid
• Version 2: DCE-based
• Version 3: UUIDs based on a namespace and then it is MD5 hashed
• Version 4: Random generation (based on the output of random_bytes

He also includes examples of the UUIDs output by each method (not much difference there as the structure of the resulting UUID is all the same).