Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

QaFoo Blog:
Using Mink in PHPUnit
Apr 06, 2016 @ 09:13:30

The QaFoo blog has a new post today showing you how to use Mink with PHPUnit. Mink is a testing tool that allows you to write tests as if they were happening through a browser.

Another day for a short PHPUnit trick. If you want to use PHPunit to control a browser for functional or acceptence tests, then you can easily do this using the Mink library. Mink is well known from the Behat community to facilitate Behaviour-Driven Development (BDD), but it is a standalone library that can be used with PHPUnit just as easily.

This is more flexible than using dedicated browser abstractions such as Selenium directly from PHPunit, because you can switch between different implementations or even run tests with multiple implementations using the same code base.

They start with the command you'll need to get Mink installed via Composer (a simple require) and come example code for a test on the Wikipedia site (the page about PHP). They then refactor this a bit to remove the boostrapping of the Mink client into a reusable trait, making it simpler to use in other tests. They also refactor the test to use the trait and include the phpunit.xml configuration needed to run it.

tagged: mink browser test phpunit install example trait refactor wikipedia

Link: https://qafoo.com/blog/081_phpunit_mink_functional_tests.html

Jesse Schutt:
Simplifying Conditional Expressions
Apr 04, 2016 @ 14:47:43

Jesse Schutt has posted a set of helpful hints around simplifying conditional expressions in your PHP code. This can not only make them more readable but also easier to maintain in the future.

As I’ve been reading through Refactoring by Martin Fowler, I’ve found it helpful to rewrite some of the examples from the book in PHP in order to cement the concepts into my mind. While Martin’s examples are primarily in Java, I’ve found an overwhelming majority of the concepts apply to PHP, which is where I spend most of my programming time.

In today’s article, I will attempt to rework the Simplifying Conditional Expressions (pp. 237-270) section into a handful of PHP-based examples.

He touches n a few different types of conditional refactoring and provides examples for each:

  • Decomposing the Conditional
  • Consolidate Conditional Expression
  • Consolidate Duplicate Conditional Fragment
  • Replace Nested Conditional with Guard Clause

He ends the post with a reminder about why refactoring like this is important to both you and your code:

Computers excel at taking sets of instructions and stepping through them systematically. They don’t need code to have informative method or variable names. They don’t even need the code to be formatted in a specific pattern (aside for the syntactical requirements). Our goal in simplifying conditional expressions should be to make the code read easier for humans, not for computers.
tagged: simplify conditional expression example refactor tutorial

Link: http://zaengle.com/blog/simplifying-conditional-expressions

Intracto Blog:
Paying Technical Debt - How To Rescue Legacy Code through Refactoring
Mar 17, 2016 @ 09:36:16

On the Intracto blog there's a new article posted from Jeroen Moons with some suggestions you can use to pay down technical debt in your legacy code through a bit of effective refactoring.

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

He gives lost of different suggestions for things that can be done to "save your code" and make it not only easier to maintain but more flexible:

  • Persuading the customer
  • Don't replace [a huge mess] with a new one
  • Make problems visible
  • Fight what hurts most
  • Build a library

There's plenty more great suggestions here too with some thoughts and methods to back them up and help you accomplish them in your own code. If you're suffering through a large legacy codebase from day to day, I highly recommend reading through this article.

tagged: technicaldebt legacy legacycode rescue opinion method refactor

Link: http://marketing.intracto.com/paying-technical-debt-how-to-rescue-legacy-code-through-refactoring

Ethode.com:
Fixing Spaghetti: How to Work With Legacy Code
Jan 27, 2016 @ 12:09:38

On the Ethode.com blog they've shared some hints for working with legacy code to help you more effectively refactor your way out of the "spaghetti code" you might have right now. These are more general tips and aren't really PHP (or even really web application) specific but they're a good starting place for any refactoring effort.

Legacy code is software that generates value for a business but is difficult for developers to change. [...] The longer this goes on, the more frustrated customers get with the software due to quirky defects, bad user experiences and long lead times for changes. Developers are afraid to make changes due to the "Jenga effect" -- as one piece of code is changed or removed, it often leads to new defects being introduced in the system in sometimes seemingly unrelated places. This compounds into what is known as "technical debt".

They continue on talking about what "spaghetti code" is, how it can happen and some of the warning signs you can use to determine just how far down the rabbit hole you and your code are. They talk about "The Big Rewrite" everyone dreams of but points out that this is almost never a practical path. Instead they offer some good things you can do to help fix the problem: quarantining the problem, refactoring relentlessly, keeping it simple and "doing the dishes" as you go rather than letting the changes pile up.

tagged: legacy code refactor opinion advice fix software development

Link: http://www.ethode.com/blog/fixing-spaghetti-how-to-work-with-legacy-code

Loïc Faugeron:
Decouple from Frameworks
Oct 06, 2015 @ 09:48:23

In this recent post to his site Loïc Faugeron shows his support for a pretty common "battle cry" among developers that make use of one of the many PHP frameworks out there: decouple from your framework (including a few strategies how).

Frameworks solve infrastructure problems, for example how to create a HTTP or CLI application. While necessary, those concerns don't add any value to your project: the business need will not be fulfilled by creating an empty application. As always, different responsibilities mean also different reasons to change: frameworks have a history of Backward Compatibility (BC) breaks and they do so regardless of your project.

[...] Does that mean that we shouldn't use any frameworks? Should we just don't care and embrace fully frameworks? This article will explain how to avoid both extremes, by decoupling from the framework. It can be done by restricting the framework to its infrastructure responsibilities (HTTP, CLI), by only using its entry points (Controller, Command) and by using the Command Bus pattern.

He uses a simple application to illustrate his points, starting with a basic Symfony installation with PHPUnit and PHPSpec installed. He builds a listener to handle JSON encoded content input and sets up the initial "Quote" controller that will take in the new request. He follows the TDD mentality along the way, testing first then writing the code to match the test. With that system in place, he talks about the ideas of commands (from the "command bus" world) and how that could be used to refactor out the "submit" logic and make it less dependent on the framework it lives in. This lets the framework handle the low-level functionality (HTTP request/response, routing, etc) while the logic sits in a more abstract, contained location.

tagged: decouple framework opinion commandbus refactor encapsulate

Link: http://gnugat.github.io/2015/09/30/decouple-from-frameworks.html

Mattias Noback:
Refactoring the Cat API client (3 Part Series)
Jul 16, 2015 @ 11:25:54

Mattias Noback has posted a three part series of tutorial articles around the refactoring of a "CatApi" class. These articles take the class from a jumbled mess of functionality with both direct file access and remote requests mixed in into something much more maintainable and flexible.

t turned out, creating a video tutorial isn't working well for me. I really like writing, and speaking in public, but I'm not very happy about recording videos. I almost never watch videos myself as well, so... the video tutorial I was talking about won't be there. Sorry! To make it up with you, what follows is a series of blog posts, covering the same material as I intended to cover in the first episodes of the tutorial.

In part one he introduces the current state of the "CapApi" class and some of the problems with it, both in testing and in structure. He does some basic refactoring to split out some of the logic here and moves on to part two. In the second part of the series he focuses on refactoring the HTTP request and the local file system functionality into abstract, injectable objects. Finally in part three he adds in some verification around the data being passed back and forth between objects including both simple checking and the use of value objects.

tagged: refactor api class series part1 part2 part3 filesystem http request xml validation

Link: http://php-and-symfony.matthiasnoback.nl/2015/07/refactoring-the-cat-api-client-part-1/

Snack Overflow:
Unit testing static calls without refactoring the world in php
Feb 27, 2015 @ 11:55:06

The "Snack Overflow" blog (from tech.graze.com) has a recent post sharing some suggestions to help unit test static calls without having to "refactor the world" away from them.

Imagine you have a situation [using a static method call] in some legacy code. Currently we can't unit test this as we can't mock out the doSomethingElse() call. So what do we do? Well we have two options really [...] neither of which is very appealing. [...] There is, however, a third option that gains us the ability to unit test Foo without having to touch Bar at all.

This option involves creating a "proxy" object of the "Bar" class that's non-static and only returns the result of the previous class' static method. You can then correctly mock that class and return the result in a more self-contained way. He lists a few caveats with this method including the fact that it could lead to a lot of proxy objects if there are a lot of static methods to replicate.

tagged: unittest static method refactor proxy object mock tutorial

Link: http://tech.graze.com/2015/02/26/unit-testing-static-calls-without-refactoring-the-world-in-php/

Mathias Verraes:
How Much Testing is Too Much?
Jan 02, 2015 @ 11:55:43

In his latest post Mathias Verraes poses the question of how much testing is too much? At what point does testing actually become less useful and how much you really need.

Figuring out how much unit tests you need to write, can be tricky, especially if you are new to Test-Driven Development. Some teams strive for 100% code coverage. Some open source projects even announce their test coverage on their GitHub profiles – as if coverage is an indicator of quality. Coverage only measures the lines of code that are executed by the test suite. It doesn’t tell you whether the outcome of the execution is actually tested, let alone how valuable that test is. Because of that, code coverage of your entire code base is a pretty lousy metric.

He suggests that the "it depends" answer to "how much testing is enough" question just isn't good enough. He puts most of this in the context of TDD (where testing is built-in to the development time) but some of the thoughts could apply to post-code testing as well. He also talks about over-design and how it relates to refactoring with deeper insight. Finally, he talks about a subject not mentioned much in testing articles - when to delete tests.

tagged: unittest testdrivendevelopment tdd too much overdesign refactor delete

Link: http://verraes.net/2014/12/how-much-testing-is-too-much/

NetTuts.com:
Refactoring Legacy Code - Part 11: The End?
Oct 27, 2014 @ 13:36:14

NetTuts.com has completed their series on refactoring with the posting of part eleven today: "The End?" This post finishes off a series where they've moved from the most basic level of testing out to a complex set of tests that can ensure your code's quality and functionality even after making their recommended refactoring changes.

In our previous lesson we've learned a new way to understand and make code better by extracting till we drop. While that tutorial was a good way to learn the techniques, it was hardly the ideal example to understand the benefits of it. In this lesson we will extract till we drop on all of our trivia game related code and we will analyze the final result.

They start off by "attacking the longest method" (wasCorrectlyAnswered) by starting the testing process. They make some simple checks to ensure the output is correct for various circumstances and values. With these tests in place, they safely refactor the method, splitting it up into functional pieces and completely dropping the method in favor of more targeted handling. They finish off the post with a look at some final results and comparing the refactored code with the original on things like lines of code, complexity, dependencies and structure (using this tool).

tagged: refactor legacy code part11 series end correctly answered

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-11-the-end--cms-22476

NetTuts.com:
Refactoring Legacy Code - Part 10: Dissecting Long Methods with Extractions
Sep 19, 2014 @ 09:41:54

NetTuts.com is back with the latest part of their "Refactoring Legacy Code" series for PHP. In this latest article (part 10) they work on pulling apart longer methods into smaller, more manageable chunks.

In the sixth part of our series we talked about attacking long methods by leveraging on pair programming and viewing code from different levels. We continuously zoomed in and out, and observed both small things like naming as well as form and indentation. Today, we will take another approach: We will assume we are alone, no colleague or pair to help us. We will use a technique called "Extract till you drop" that breaks code in very small pieces. We will make all the efforts we can to make these pieces as easy to understand as possible so the future us, or any other programmer will be able to easily understand them.

This "extract 'till you drop" mentality (from Robert Martin) has you look at a piece of code and find the logic and lines that can be split out and isolated without removing functionality and interaction. They include some random code from a Stack Overflow post (checking if a number is a prime) and show how to split it out, making the logic and structure less complex and more understandable. They start with a unit test to ensure the result is the same post-refactor and fixing a few bugs along the way. They split it out into two different methods and move it from a more linear approach to something recursive.

tagged: tutorial refactor legacy code part10 series extract method

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-10-dissecting-long-methods-with-extractions--cms-22182