Robert Basic has a new post to his site with some advice for the Behat users out there testing their Symfony applications. He shows how to easily load up fixture data with the help of Doctrine.

Performing end to end testing of any application requires from us to have a set of reliable test data in the database.

If we write a Symfony application and use Behat to do the end to end testing, the we can use the Doctrine fixtures bundle to create the required fixture loaders and load them in our Behat scenarios when required.

He walks you through the installation of the Doctrine fixtures bundle (via Composer, naturally) and how to enable it via the Symfony kernel configuration. He then includes an example of the fixture loader class from the FOSUserBundle and how it works. Next up is the installation of the Behat Symfony 2 extension and a bit of extra code to make a new feature context for Behat containing a "loadDataFixtures" method to do the heavy lifting.

In a recent post to his site Matthieu Napoli shows you how to use the recently added anonymous classes functionality to help make your unit tests simpler. Anonymous classes allow for the on-demand creation of class instances without the need for the predefined class being required.

Anonymous classes were added to PHP 7. This article intends to show how useful they can be for writing tests.

He breaks it down into the three most useful places he uses them in his tests:

• mocking classes to make it simpler to test method output
• spies looking at properties in the mock class
• fixture classes to help with needs such as reflection tests

Code examples are provided for each of the examples, especially the final point there.

On the SitePoint PHP blog author Andrew Carter has shared a "quick tip" about using a disposable database in the testing of your Symfony-based applications.

Testing code that interacts with a database can be a massive pain. Some developers mock database abstractions, and thus do not test the actual query. Others create a test database for the development environment, but this can also be a pain when it comes to continuous integration and maintaining the state of this database.

In-memory databases are an alternative to these options. As they exist only in the memory of the application, they are truly disposable and great for testing. Thankfully, these are very easy to set up with Symfony applications that use Doctrine.

He talks first about the built-in functionality Symfony has to use different configuration files for different environments. This allows for easier testing in a more isolated setup than replicating development. He then shows how to use Doctrine with a SQLite in-memory database with a simple update to the config_test YAML configuration file. He also includes the code for a DatabasePrimer class that gets the Doctrine entity manager and executes the the schema tool to set up the schema in the database and "prime" it with any fixtures you might need.

On the TutsPlus.com site they've posted a new tutorial showing you how to do test-driven development with Laravel and Doctrine, making use of Doctrine's own testing functionality inside of a Laravel application for PHPUnit based unit testing.

As a PHP developer, you may use the Test-Driven Development (TDD) technique to develop your software by writing tests. Typically, TDD will divide each task of the development into individual units. A test is then written to ensure that the unit behaves as expected. [...] TDD verifies that the code does what you expect it to do. If something goes wrong, there are only a few lines of code to recheck. Mistakes are easy to find and fix. In TDD, the test focuses on the behavior, not the implementation. TDD provides proven code that has been tested, designed, and coded.

[...] PHPUnit is the de-facto standard for unit testing PHP. It’s essentially a framework for writing tests and providing the tools that you will need to run tests and analyze the results. PHPUnit derives its structure and functionality from Kent Beck’s SUnit.

He briefly talks about some of the assertions that PHPUnit has to offer before getting into the support that Laravel includes and how to configure it so Doctrine can work with your database. He then talks about Doctrine, briefly introducing the popular database abstraction tool and how to integrate it with a Laravel application. From there he starts in on the tests themselves, showing code that uses fixture data to create several tests for Post and Comment data.

The SitePoint PHP blog has posted a tutorial from Taylor Ren looking at the use of fixtures in Symfony2. Fixtures allow you to create a set of test (or just initial) data to populate the database in an automated way.

Back when I first started to learn Symfony (1.x) with its Jobeet project, I thought the ability to load a bunch of test data into the database very useful. In this article, we will revisit this feature, which has been completely re-modeled and thus has a lot to teach us.

He uses two third-party libraries to give the Symfony application a bit more "power" - the DoctrineFixturesBundle and PHPUnit. The second is used for testing the results of the fixtures, not the actual loading process. He walks you through the creation of your first fixture file for a book-based example. The fixture uses the Doctrine functionality to create "place" data. He includes the command to run the fixture (via the Symfony app/console command) and what the result should look like. He comes back around and shows the same process with other general book data, also talking about primary keys and references.

Michelangelo van Dam has shared something new he learned at the recent ZendCon conference about using fixtures with his PHPUnit testing.

In my previous post I already mentioned Sebastian Jerzy Wilczyński (@dj_sebastian_w) and his uncon session "Unit Testing for Databases using fixtures and phpunit". It made me wonder how much difference it would make if you use fixtures instead of testing database interactions using predefined sets of data. Since I work a lot with Zend Framework I was looking at how I could use fixtures and mock objects to follow Sebastian's guidelines. So I gave it a try. This is what I came up with.

He illustrates with some example code - a set of database data (the fixtures) and sample tests that use the Zend Framework's mapper and table gateway functionality to work with the tables. His test then mocks out the DbTable class for the "Order" object and forces a return of the database fixture data.

Carl Vuorinen has a recent post to his site showing you how to unit test your Zend Framework (v1) controllers with the help of database fixtures to provide the test with valid data.

So I started thinking that there must be a way to use fixtures for the database the same way as when testing models with PHPUnit Database extension (PHPUnit_Extensions_Database_TestCase). But since PHP does not have multiple inheritance, we can’t extend both Zend_Test_PHPUnit_ControllerTestCase and PHPUnit_Extensions_Database_TestCase. So I started out to create a controller test case class that has support for fixtures the same way as the database test case. I mean, how hard can it be?

He dug into the code for the extension and finally came up with a working solution - an abstract class with "_setup" and "_setupDatabase" methods that create what you'll need to perform your tests. A sample test is included in the post to show you it in action.

Joshua Thijssen has a new post to his blog looking at a method for setting up ACL rules in fixtures for your Symfony2-based applications.

Doctrine’s DataFixtures are a great way to add test data to your application. It’s fairly easy to get this going: Create a fixureLoader that extends DoctrineCommonDataFixturesAbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2′s ACL layer. Since there isn’t a common way to do this, here is one way on how I implemented this.

His method uses the ContainerAware interface on the fixture loader instance to be able to get at the container for the fixture. This allows you to use the usual ACL handling methods of the framework to provide restrictions based on things like usernames and roles.

Michael Nitchinger has a new post to his blog about a rewrite for the Lithium framework - changing up the li3_fixtures plugin to make it a bit more of what the community needs.

The li3_fixtures plugin was my first Lithium plugin ever, and while it works okay, I feel there is a lot I can do to make it better and more flexible. In this post I want to share my ideas for a new fixture plugin and also want to gather feedback from the community to make it even more awesome.

He gives three instance where fixtures can come in extremely useful - making effective model unit tests with predictable data, mocking models with shortcuts to the data and mocking out web services. Want to add in your own suggestions for his refactor? Comment on the post!

Sebastian Bergmann has two recent posts dealing with some of the more difficult topics in unit testing. One looks at sharing fixtures between tests and the other talks about stubbing and mocking static methods in your tests.

From the first of the two tutorials:

A good example of a fixture that makes sense to share across several tests is a database connection: you log into the database once and reuse the database connection instead of creating a new connection for each test. This makes your tests run faster.

This fixture sharing example uses the setUpBeforeClass and tearDownAfterClass methods to create and destroy the connection.

In the second article Sebastian shows how to mock up a sample static function and mock it with the "staticExpects" helper.