In this post on Medium.com Ond?ej Mirtes introduces a tool that can be use to statically analyze your PHP application and locate bugs without the need for tests - PHPStan.

Keeping up with modern PHP practices leads to codebases where we can be sure about types of a lot of data, converging with statically typed languages, although the dynamic nature is still present. Modern PHP codebases are similar to the ones in languages people make much less fun of. Object-oriented code, dependency injection and usage of established design patterns are truly common nowadays.

Which led me to the idea of a static analysis tool for PHP that would substitute the role of the compiler from other languages. I’ve spent a lot of time working on it and I’ve been employing its various development versions checking our codebase for more than a year.

It’s called PHPStan, it’s open-source and free to use.

The post goes on to talk about some of the checks that PHPStan performs (with more information available in the project's README). He also talks about the performance of the tool, how to extend it and configuring it for "strictness". He ends the post by pointing out that, despite the title of the article, he still encourages writing tests, just making sure they're "meaningful ones" that test more than just syntax.

php[architect] magazine has officially announced the release of their last issue for 2016: the December 2016 edition - "Scrutinizing Your Tests":

The twelfth issue of 2016 is now available! This month we look at how to write good tests with Behat and using Test Driven Development. This issue also includes articles on using HTTPlug to decouple your HTTP Client, Decoupled Blocks with Drupal and JavaScript. Our columnists have articles on writing a Chat bot, advice on securing your application’s secrets, making better bug reports, respecting diversity, and a look back at 2016.

This issue includes articles like:

• "Strangler Pattern, Part Three: the Rhythm of Test-Driven Development" (Edward Barnard)
• "Decoupled Blocks with Drupal 8 and JavaScript Frameworks" (Matt Davis)
• "Leveling Up: Building Better Bug Reports" (David Stockton)
• "Community Corner: Focus on What We Have in Common" (Cal Evans)

And, as always, they provide a free article so you can get a feel for the content of the magazine. This month's talks about Behat by Konstantin Kudryashov. You can pick up a copy of your own directly from the php[architect] site.

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.

In this post to his site Joe Ferguson gives some advice on solidifying tests in your system that are a bit more fragile. Every test suite of any larger size has these kinds of tests - ones that usually pass but sometimes fail (and then pass just fine on the next run).

On my first week at the new job I was tasked to fix some tests that were logging data. While the fix was simple enough, by using `PsrLogNullLogger as Logger` instead of `MonologLogger` in the test, during the process I ran into another test that appeared quite fragile.

He gives an example of a fragile test, one based on a method that returns a "food" value, that would potentially fail if the data returned is not in the right order. He found the issue was with the use of the assertArraySubset check and how, thankfully, the fix was as easy as changing the assertion (and using an array_diff to help with the check).

On the QaFoo blog there's a new post sharing some helpful hints that you can use to refactor your code without breaking things in a legacy codebase.

Refactoring means to change the structure of your code without changing its behavior. It is an essential part of everyday programming and should become knee-jerk for your whole development team. Refactoring is very helpful to cleanup feature spikes, revise earlier decisions and keep a maintainable codebase in the long run. In a perfect project world - with extensive automated tests of various types - this is just a matter of getting used to. But there are only very few such projects. So getting into proper refactoring is much harder. This article will show you important tips to master this challenge with your team.

They point out two things that can help you ensure you break as little as possible: good tests and "baby steps". They go into a bit more detail on these two sections, mentioning how they help with the refactoring process and techniques to follow in the process.

The Laravel News Podcast has released their latest episode, Episode #13 hosted by PHP and Laravel community member Eric L. Barnes.

In this episode, we talk about Laravel Exception Reporter, Chrome Bandwidth limiter, Chrome extension to generate Laravel tests, Jigsaw, Helpspot Vault, Fixing MySql Memory, Sparkwatch, and Taxes.

You can listen to this latest episode either using the in-page audio player or by subscribing either through iTunes or their RSS feed.

Loïc Chardonne has posted the latest part in his "Symfony Differently" series (part one is here) with a focus on bootstrapping the application and configuring the environment that it will live in.

Our goal in this post is to bootstrap an application to then create a search endpoint for items. We've decided to use Symfony for a single reason: our company Acme used it since the beginning and the API developers team has Symfony and PHP skills.

He walks through the steps you'll need to get the application up and running:

• Creating a new Symfony Standard Edition project
• Configuring Apache
• Moving the tests to a different directory, including Composer updates
• Creating scripts for builds, testing and deployment

With all this structure in place, the next part of the series will start in on the functionality of the search endpoint and returning the results.

On the VG Tech blog there's a recent post showing you how you can use the built-in PHP web server to help with running your Behat (a behavior-driven development tool) tests.

Behat is a tool for running acceptance tests for your application. If your application is a web application you will need a web server to execute your tests. [...] Some weeks back I wrote a post showing you how to use PHP’s built in web server in PHPUnit. This post will show you how to do the same for Behat when running your acceptance tests.

His example (here on github) shows you how to set up Behat via Composer, run it and start in on your first test. In the test's "setUp" method, it calls out to the command line and starts up the built-in web server if it's not already running. It also checks to see if it can connect to the server to make sure it's accessible. Then, in the "tearDown" method, there's a call to kill off the PHP process based on the PID stored on startup.

Fabien Potencier (of the Symfony framework) has a new post to his site talking about a philosophy that the Symfony framework community should work towards, providing stability over features.

Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

He highlights some of the points that come along with this effort including less refactoring for the sake of refactoring, fixing more bugs/edge cases and writing more tests/documentation. He gets into some of the specifics of this kind of thinking and points out the things that can and can't be changed during this time. He talks more about stability and suggests that not only can it help enhance performance but it could also help motivate more projects/corporate users to start using the framework.

Hari K T has a new post to his blog that shares his concern about a "design flaw" in the component/package methods promoted by Symfony2 and Zend Framework 2:

Looking from outside both Symfony2 and ZF2 is full of standalone components. But the reality is not the same. Though Symfony2 components are split into each components in github, you cannot give a pull request to that component. The tests for all the components still resides in the core.

He points to the Aura framework project as a good example of how to make a truly component-centric set of tools complete with tests bundled into the component's download right next to the source.