The QaFoo blog has posted a new article sharing five tips to improve your unit testing of your PHP applications. Even if you're a testing veteran, there's some helpful hints in here for you.

After you got the hang of unit testing there is still so much space for improvement. In this post I want to share five tips with advanced testers I have seen to influence testing in the right direction.

Their list of five tips includes advice about what you should consider as a "unit", refactoring test code and writing tests for bugs. Each topic includes a brief description of the suggestion and clear steps to follow when integrating it into your testing workflow.

The Toptal.com blog has posted a new tutorial that wants to help you make the most of your application via testing. They show you how to use Codeception to create a set of tests to ensure your application is working as expected.

Before moving on to Codeception and PHP, we should cover the basics and start by explaining why we need testing in applications in the first place. Perhaps we could complete a project without wasting time on tests, at least this time?

Sure, you don’t need tests for everything; for example, when you want to build yet another homepage. [...] However, you definitely do need testing when: your team uses BDD/TDD, your Git repo contains more than a couple commits, [and] you are a proper professional, working on a serious project.

They start with a look at the kinds of things testing solves in your development process and the different kinds of tests you can create. From there they introduce Codeception, an alternative testing tool to the widely used PHPUnit. The tutorial helps you get it installed and shows you how to make a simple, first test. It helps you execute the test, debug issues that might pop up and the different assertions you can use. With the fundamentals in place, they move on to more details on using it for functional and unit testing.

In a new tutorial Dalibor Karlović shows you how to test your Symfony application in production to get a more "real world" picture of how your application is performing for the rest of the world.

The problem here is that you almost cannot guarantee that you can replicate the production environment down to a single detail, it might have a slightly different underlying system, a slightly different network setup, even a different updates applied might mean it works for you, but not on production.

He starts the post by talking about the testing support already built into Symfony and the different parts tested by unit versus functional tests. He gets into some actual (functional) test examples, showing how to evaluate the response from an API request and where the major part of the overhead is - the database interaction. He takes the next step and looks at how to avoid "impure" functional testing and only then starts talking about switching between database types (SQLite vs MySQL) for better performance measurements. Finally, he gets to the topic of the article, running tests in production, and includes a "gotcha" to look out for (hint: don't hard-code IDs).

Rami Alnawas has posted an interesting tutorial for the Phalcon users out there showing one way you can unit test your models. It's based on his own experience with the framework in a current project.

My first contribution to the PHP community in general, and Phalcon folks in particular, was the introduction of MVC Functional Testing with PHPUnit, this meant that Applications developed using Phalcon Framework could be unit tested by requesting a url then asserting that the response is handled by a specific action within the controller. [...] To date, my latest addition is an example of how to unit test code that utilises Phalcon models, mainly the various static find methods. The code is available on github and the coverage report is coveralls.io.

He shows it at work, creating a simple "Popup" model and a facade to help with making instances for testing. He also includes the code to test this facade, checking the results of methods like "fetchall", "select" and "execute".

On the Codeception blog there's a new post that advocates getting on the testing ship even if the project you're currently on isn't using tests (or TDD).

In this blogpost we will try to figure out how to get faster into the testing. What tests to write at first? Let's say we already have a project and we didn't practice TDD/BDD developing it. Should we ignore testing at all? Definitely no. So where should we start then?

They suggest a three-tiered pyramid approach - UI at the top, Integration testing in the middle and Unit testing as the foundation. They talk about the times when testing doesn't make sense, like when your application is based on a third-party tool (like WordPress or Drupal). They recommend starting with functional testing and working your way back down, especially if your framework supports it. Obviously they encourage the use of Codeception for it, but also recommend even something like Selenium tests if nothing else.

Anna Filina has a new post to her site that helps to clarify the definitions between functional, unit and integrations tests of your application's functionality.

I have recently read a blog post claiming that functional tests are not “true” tests. The author also claims that unit testing shows you where the problem is occurring, while functional testing simply identifies that a problem exists. This argument is deceptive and the conclusion dangerous. Different kinds of tests are not mutually exclusive. One is not superior to the other. They have different goals and can happily coexist. Let me explain the kinds of tests so that you could make enlightened decisions.

She covers each type of test in detail, noting the goal of that particular type and some examples of the kinds of things they might test. She starts with the highest level, functional testing, then jumps down to the lowest - unit testing. She finishes up the post defining "integration tests" as tests that ensure you're integrating correctly - that you're using the API provided by the tool in the right way and that it's working as expected.

Chris Hartjes, a big proponent of testing in web applications (mostly in the PHP realm so far) has a new post to his site with some of his thoughts about PHPSpec, the specification-driven testing tool recently released by the same folks who made Behat.

I think that we are witnessing the first wave of new testing tools in the PHP community that allow developers to wrap their applications in automated tests. I am familiar with the BDD-style that is being promoted in PHPSpec, through my work with Behat to create automated user acceptance tests. I think if you want a tl;dr version of PHPSpec I would tell you “write hybrid unit/integration tests using plain language”.

He notes that writing code to match a specification has similar concepts to using unit testing for TDD (with something like PHPUnit). He points out a few interesting things like the use of mock objects and the fact that you'll still need to write some code to make tests work - that's unavoidable right now.

On the Codeception blog (an up and coming PHP-based testing tool) there's a new post showing how to use the tool to test your web services for either a SOAP or REST-based service.

Codeception testing framework got significant improvements during last week. The first and the major one is that you don't even need PEAR and Composer to execute tests. Only one file codecept.phar required. This might save your time and mind of your testers.

They've recently added modules for SOAP and REST support, making it easier to define your tests in a more fluid fashion. Included in the post are two examples, one REST and one SOAP. You can find more information about these new testing features over in the tool's documentation.

Volker Dusch has a new post reminding us about what the "unit" part of "unit testing" means - small chunks of testable parts in an application.

What does the word UNIT in unit testing stand for? Think of an answer and read on! So? Did you say “A method! Because we test methods!”? If so let me offer another perspective.

He suggests that, rather than about just the methods in the class, it's more about testing the "observable behaviors" of the class. That is, anything that you could publicly use the class for and have something happen. He gives examples of this shift in focus - calling setValue and evaluating the result versus just calling the class property itself (then calling the method). He also includes a bit about testing behaviors - what happens when my script does [this] and how does that effect the overall class.

When your tests fail but the class “still works” and you need to “fix the tests” the your tests are worth a lot less as they don’t really give you that cozy safety net that they should provide you with.

On PHPBulder.com there's a new tutorial posted showing you how to create an application that can do unit conversion with the help of the Zend_Measure component of the Zend Framework.

Performing even relatively simple conversion calculations such as from pounds to kilograms from memory can be fairly difficult, let alone calculating more esoteric conversions such as from square meters to acres. To automate this conversion process, I used the Zend Framework to create a calculator capable of easily migrating data among the most commonly used formats.

Zend_Measure lets you define the type you want to convert from and convert to based on some constants included with the component. A simple call to the "convertTo" method and you'll get your answer. Based on this he creates a simple calculator and shows you can can integrate roman numeral support in as well.