On the Laravel News site there's a new tutorial posted introducing you to testing with PhpSpec, a specification-driven testing tool that helps you model the specification your application needs to match.

PhpSpec is a testing tool based on the concept of emergent design using specification. You may have heard of Behavior Driven Development (BDD), and PhpSpec is a tool to use at the spec level or SpecBDD. We also mentioned PhpSpec in our recent roundup of Laravel Testing Resources, which includes ways you can incorporate PhpSpec into your Laravel workflow if you are interested in trying out SpecBDD.

If you’ve never tried PhpSpec, one of the things that I love about PhpSpec is that the process generates code for you and guides you through the SpecBDD process through the command line. Let me show you what I mean with a quick tutorial.

The tutorial then walks you through the installation of PhpSpec and how to run it from the command line before making any tests. They then walk through the configuration of the tool and share a sample workflow with seven steps including describing a specification, writing out expected behavior and verifying the behavior. Code examples (and command line calls) are included in each step of the way, defining an example "calendar" specification with the common functionality (add, subtract, divide, etc). The post finishes with some links to where you can find more information about PhpSpec and spec driven development.

On the SitePoint PHP blog they've continued their series looking at upgrading Sylius, an e-commerce application based on Symfony, with the help of test-driven development methods to ensure nothing breaks along the way. These next two articles cover the use of PhpSpec and using Behat for the different types of testing.

Last time, we developed some new features on top of Sylius’ core to indicate which products and their variants are low on stock and need replenishing. Now, we move on to seeing our changes in the UI, which means we will need to do a bit of StoryBDD testing.

In [the third] part, [we] extend some core classes to indicate color-coded inventory status. First, we’ll deal with the back end part. In a followup post, we’ll use Behat and test the visual changes. Please follow the instructions in the previous post to get a working instance up and running.

In each of the tutorials they walk you through the changes you'll need to make on the Sylius side to test both the Inventory and Product functionality that already come with the package. Examples of each kind of test are included as well as the output from the example test runs.

Loïc Faugeron has posted the latest in his "Mars Rover" tutorial series to his site today. In this new post he migrates some previously created objects over into their own package to help with reporting back the rover's location.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location. In this article we're going to move geolocation value objects (Location, Coordinates and Orientation) into their new package (geolocation).

He then moves over the files relating to these objects into the "Geolocation" directory and fixed the namespace to reflect the update. Tests are all still passing so he moves over to the "navigation" package and fixes a few places in the tests where these objects were mentioned (doing the same for the "orientation" handling). This finishes out the series with a complete set of classes and objects reflecting the requirements. He summarises the work that was done, how the resulting code is structured and the major role that the phpspec testing played in the whole process.

Loïc Faugeron has continued his "Mars Rover" series with this latest article posted to his site. In this most recent tutorial he takes some time to refactor some of the current "locating" code and make it fully functional.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD).

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location: Mars rover will be requested to give its current location (x and y coordinates and the orientation). In this article we're going to create the locating logic.

He starts with the phpspec tests for the Location handling and edits the generated test to integrate the "coordinates" and "orientation" checks. When this test runs phpspec generates the "Location" class with basic logic. This is updated as well with real functionality and the "LandRover" class is then refactored to make use of all of this new functionality. The final code for the "LandRover" class is also included for reference, post-refactor.

Loïc Faugeron continues his "Mars Rover" series of posts today with the latest in the series covering the "Locating" handler, the functionality responsible for handling requests for the rover's location.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location

He makes use of the command bus pattern to create the handling for the module, doing validation in the Command object and a Bus to handle the command and perform its task. He starts, as usual, with the phpspec tests defining a class that can use a "find latest location" type instance and a "find" method to abstract out the location repsonse.

Loïc Faugeron continues his long running series covering the creation of a "Mars Rover" package to help teach programming fundamentals. In this latest tutorial he starts on the last use case in the project: requesting the location of the "rover".

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD). We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now going to start developing the last one, requesting its location:

Mars rover will be requested to give their current location (x and y coordinates and the orientation).

In this article we're going to create a new package for the location logic.

He starts by giving a justification as to why a new package is being created just for the location requests (when the navigation package could just be asked for that information). With that explained, he starts in on creating the new package and its tests with phpspec. He then adds this package into the current project's Composer configuration and updates the phpspec configuration to tell it about the newly creates code.

In this latest post in the series Loïc Faugeron continues his "Mars Rover" tutorials, this time with a focus on creating the logic that will "drive" the rover around.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD).

We've already developed the first use case about landing the rover on mars, and we've started the second one about driving it. [...] In this article we're going to create the actual driving logic, using Event Sourcing.

He follows the "Command Bus" design pattern and creates the command structure for the DriveRoverHandler to handle the logic related to the DriveRover instance. He starts with the spec (the test) and updates the generated class with the logic in the handle method to record an event happening on the DriveRover instance. He make a few more changes to the functionality for the spec and class to make the tests go green.

Loïc Faugeron continues his series of "Mars Rover" posts with this new article focusing on a refactor of the currently defined method of "driving" the rover.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) [and] Test Driven Development (TDD).

We've already developed the first use case about landing the rover on mars, and we've started the second one about driving it. [...] In this article we're going to refactor DriveRover

He points out the reason for the refactor: there could be a desire to have more that one driving instruction in the list to execute. He starts by using phpspec to define the "Instruction" class and some tests to ensure the different directions are handled. He then moves over to the "Instruction" test and moves the code from the "DriveRover" class into it, including the valid driving directions.

Loïc Faugeron continues his series of "Mars Rover" tutorial posts with the latest covering the driving of the rover.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES), Test Driven Development (TDD)

We just finished developing the first use case, so we can now get cracking on the second one, driving the rover.

As is tradition in this series, he starts with the phpspec testing, defining the DriverRover spec requiring driving instructions to be provided. He generates the code for it and fills in the brief functional details handling the instruction property. He also adds in some validations as far as what instructions it can be given and re-runs the tests to ensure they all pass.

Loïc Faugeron has continued his series developing the code for a "Mars Lander" coding exercise with this latest post sharing the actual code for the event sourcing functionality started in the previous tutorial.

In this series we're building the software of a Mars Rover, according to the following specifications. It will allow us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD). Up until now, we've implemented the first use case, "Landing a rover on Mars".

We've also created an event-sourcing package with the following interfaces: Event, AnEventHappened and EventStore. In this article, we're going to implement them.

He then starts in using phpspec to generate the Event class for him and gives it a basic structure. He fleshes this out with a bit of functionality (to make the tests pass) and moves on to the "AnEventHappened" class. He generates the class in the same way as before and adds a "just now" method to return the event that "just happened". The last class, the "EventStore" could do different things depending on the storage method, so he's delaying that for now and will implement it later.