Larry Garfield has posted a book review to his Steemit site giving his thoughts about the "Functional Programming in PHP" book from php[architect] press.

I was asked by php[architect] a while back to review "Functional Programming in PHP, 2nd Ed" by Simon Holywell. I've been sitting on this review for a while, so it's time to finally get it done.

He starts with some of the usual disclosures about receiving the book (for free), what the review is based on and that the opinions are his alone. He goes on to share some of his initial impressions of the book and whether he feels it's a good book to recommend to those wanting to start out with functional programming in PHP. He also points out that, while the book was published in 2016 the recommended PHP version even then was quite old (v5.4). He covers some of the topics that the book covers, noting that many of them, while interesting, don't add much to the overall book.

He does focus on one chapter and how, at the beginning, it showed promise but quickly moved towards using 3rd party libraries for more complex operations. He finishes the review by answering the question: "does this book make me care about functional programming in PHP?"

Earlier this month, the Symfony blog made an announcement about a new browser testing and web scraping tool that's been released under the Symfony umbrella: Panther.

Since the very first version of Symfony 2, the framework provides a suite of convenient tools to create functional tests. They use the BrowserKit and DomCrawler components to simulate a web browser with a developer-friendly API.

The post starts with a "refresh" of the current WebTestCase helper functionality to create these functional tests. They also include an example of a repository class that stores/retrieves the news and a matching controller to handle the requests (and Twig templates for output). They then create a test using the WebTestCase functionality to get the index and ensure that some of the content is correct.

The tutorial then takes this same scenario and applies tests using the new Panther functionality. Where the WebTestCase uses a simulated browser internal to the framework, Panther uses an actual browser to run is tests using the Facebook PHP WebDriver library. They show the slight updates that would need to be made to the current test and the resulting output.

The tutorial goes on to provide other examples of tests for API requests and Javascript functionality for a Vue.js frontend. It wraps up mentioning some of the additional functionality Panther includes such as the ability to take screenshots and injecting Javascript into the pre-rendered page.

Brandon Savage has a quick post to his site sharing some advice around the testing of your application, more specifically around unit tests: don't write useless unit tests. He starts with an example of a test that, while moving the project closer to the 100% coverage number, is mostly useless.

Too often, in the search for 100% unit test code coverage, I see tests like this get written. They don’t serve a practical purpose, except to meet the test coverage goal. Worse, they don’t actually improve the quality of the application.

Instead of writing a unit test here, we would be better served by writing an integration test, or a functional test. These tests would require us to interact directly with the database, but would provide far more valuable information about the health and status of our application. A useless unit test provides us with little if any benefit; a useful functional test provides us with tremendous advantages.

He includes the code for the test and talks about what's wrong with the approach and how it could potentially be handled better. He suggests that writing good, useful tests requires both skill and determination and the avoidance of tests that actually increase the quality of the overall test suite.

In a recent post to his site Marco Perone looks at the idea of "maybe" in PHP, having functionality that acts a default value if no value is present. This idea is implemented in other languages like Haskell and Elm.

Doing functional programming in a language as PHP, which is almost completely used as an imperative or object oriented way, is not always easy. Good progresses have been made thanks to the introduction of callable type hints in PHP 5.4 and the diffusion of functional interfaces like the ones present in PSR-7.

Still, all “good” PHP code is still written using objects and classes and the object oriented perspective on the world strongly influences even the most functional oriented libraries.

In this post I would like to propose as an example how we could implement the Maybe type in PHP. We will see how some open source libraries do this, we will see an alternative solution and we will raise concerns about some modelling issues.

He starts off by describing what the "maybe" functionality is and gives some examples of it in use in other languages. He points out that while there's several PHP libraries that implement this kind of default handling, it's not in the PHP core language. He works through some of these libraries and shows them in use: monad-php, Phunkie, php-maybe-monad and php-fp-maybe. He wraps up the post showing his own suggested implementation and how it could help resolve some of the issues he found with the other libraries as he worked through them.

The SitePoint PHP blog has a new tutorial posted from author Marcello Duarte showing you how to use functional programming techniques in your applications with the help of the Phunkie library. Phunkie is a library that brings functional programming functionality to PHP. This article was originally published on the Inviqa blog.

In the first part of this series we explored parsers and combinators to help you start getting values from functional programming with PHP. We covered the basics using examples, and now we’ll move onto more sequencing and other strategies.

Continuing on, they work towards the goal of making a more useful end result, a JSON parser that returns a JsonObject. First, though, he goes through several different combinators, showing code examples for each: sequencing, choice, and recursive. He also covers the repetition pattern and how to integrate separators. Finally, with this groundwork laid, he gets to the JSON parser showing each step of the way, from reading in the JSON string to returning the object.

The SitePoint PHP blog has posted a tutorial by Marcello Duarte showing you how to use functional programming in PHP with the help of the Phunkie library.

Phunkie is a library with functional structures for PHP. In this tutorial, Phunkie creator Marcello Duarte, head of training at Inviqa, explains how to create Parser combinators using the functional library.

[...] Learning functional programming means immersing yourself in a new paradigm, which can be challenging. It requires a totally different mindset for approaching problems. So, by the time you can use functional programming to solve real-world problems, you’ll have spent hours grasping the new thinking or getting clued-up on the theory.

In this tutorial, my aim is to help fast-track your journey by going over my implementation of Hutton & Meijer’s Monadic Parser Combinators.

He starts off by defining two terms that will be used through out the code: parsers and combinators. He shares a code example of a combinator and then moves on to examples of primitive parsers and parser combinators. Each section includes the code you'll need to use (making use of Phunkie) to make the functional magic happen.

The Three Devs and a Maybe podcast, with hosts Michael Budd, Fraser Hart, Lewis Cains and Edd Mann, has posted their latest episode - Aha! Moments with Steven Proctor.

In this weeks episode we are lucky to have Steven Proctor back on the show. We start off discussion by congratulating him on 82 episodes of Functional Geekery, and the commitment it takes to do a podcast and not just ‘podfade’. From here we move on to highlight any commonalities he notices with people getting into FP, how he stays on-top of the latest advancements and how he finds the guests he wishes to speak to. This leads us on to compare learning functional concepts within a language you already know vs. in a totally different language which is rooted in the principles. Finally, we chat about interesting projects that are on his radar and advice that he has for people who wish to begin exploring FP.

You can listen to this latest episode either using the in-page audio player or by downloading it directly. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

On the Delicious Brains blog there's a post sharing some of their knowledge about building tests for WP-CLI packages, a set of command line tools for administering a WordPress installation. Their testing makes use of the Behat testing tool (already in use on WP-CLI's own tests).

My last article was part of a short series on automating local WordPress site setup. In that series, we created a WP-CLI package that helps with installing and uninstalling WordPress development environments, and we even got it submitted to the WP-CLI Package Index.

[...] In this post we’re going to take a bit of a break from automating WordPress installs and start writing some functional tests to make sure that everything works as expected. While I’ll be writing the tests for the wp installer command, the same concepts should apply for any WP-CLI package.

They start by clarifying the difference between functional and unit tests and how to get your environment all set up and ready to use for testing. They help you get the wp_scaffold_package installed and how to confirm that everything is working as expected. From there it's all about the tests: ensuring that a package is active, creating a custom step to use in testing and an example of what the output should look like.

The QaFoo blog has a post to their blog introducing page objects and how they're useful in functional testing to help provide a "decoupling" from the actual frontend.

A while ago we wrote about writing acceptance tests (end-to-end tests) with Mink and PHPUnit. While this is a great set of tools for various applications such tests tend be susceptible to changes in the frontend. And the way they break is often hard to debug, too. Today I will introduce you to Page Objects which can solve some of these problems.

The basic idea behind a Page Object is that you get an object oriented representation of your website. The Page Objects maps the HTML (or JSON) to an object oriented structure you can interact with and assert on. This is more initial work then than writing tests with PHPUnit and Mink directly, but it can be worth the effort.

They use the Mnk testing tool to simulate a browser and some previously shared functionality to lay the foundation. From there they write up a first test using a "Login" page object and processing the username/password handling of the page. They show how to implement a custom page object with a bit of additional logic and put it to use in processing the request. They also include an update when, for example, a site is switched from Twig templates to a React.js component and how the Page object would need to be refactored for the update.

Vic Cherubini has written up a tutorial on his site showing you how to write functional tests for Symfony services in your application. He provides a practical example of testing a basic Symfony service and the configuration/code to go with it.

The dependency injector is an amazingly simple and flexible addition to Symfony, and one you should be using to properly structure your application. But what happens when you want to write a functional (or integration) test for a service that depends on another service? This article will show you an easy way to test complex services.

He sets up a simple InvoiceGenerator service that takes in a Doctrine entity manager and a "payment processor" instance. He stubs out a simple PaymentProcessor class and shows the configuration needed to set it all up for correct injection. He then gets into the testing of this setup, creating a simple test case that requests the invoice generator from the service container. In this call the services_test definition overrides the default and injects the test payment processor instead of the actual one.