On the CodingItWrong site Josh Justice has written up an interesting article about the different "schools" of testing and the approaches they take. While it's not specific to PHP testing, a lot of the principles still apply.

The last few months have been my first opportunity to do automated testing at my full-time job. As I’ve been trying to get the hang of it, my biggest question has been how many of each type to test to write: how many unit, integration, and acceptance tests. Turns out Folks Got Opinions™ on this! As I researched, I found at least four different approaches to testing, and they each provide different answers to a number of questions I had.

His research answered questions about what the different types are, what processes are used to create tests and what to check for. He also answered question about how to change code based on what you find during testing and what "good code" is. HE then breaks down the rest of the article into the four different types of software testing he found during his research:

• Test Approach #1: Whatever it is DHH does.
• Test Approach #2: Classical TDD
• Test Approach #3: Mockist TDD
• Test Approach #4: Discovery Testing

Each sections includes a summary of the testing practices, links to some other resources on the topic and an illustration of the typical flow when writing the tests.

Bernhard Schussek has written up a new post to the Web Mozarts blog talking about resource discovery with Puli. Puli is a management tool for the non-PHP files in your applications (CSS, Javascript, YAML, etc). In this post he talks about the use of the discovery component and its use of resource binding.

Many libraries support configuration code, translations, HTML themes or other content in files of a specific format. The Doctrine ORM, for example, is able to load entity mappings from special XML files. When setting up Doctrine, we need to pass the location of the *.dcm.xml file to Doctrine’s XmlDriver. That’s easy as long as we do it ourselves, but what if someone else uses our package? How will they find our file? What if multiple packages provide *.dcm.xml files? How do we find all these files? We need to remove the appropriate setup code after removing a package [and] we need to adapt the setup code after installing a new package. Multiply this effort for every other library that uses user-provided files and you end up with a lot of configuration effort. Let’s see how Puli helps us to fix this.

He talks about the concept of package roles in the tool, breaking them down in resources and providers. He then shows how Puli makes it possible to discover resources by defining a type via Puli and the code for the discovery process. He then binds the XML configuration definition and executes a "find" to ensure it's configured correctly. Finally, he shows the process to use Puli in this Doctrine example allowing it to locate and use the XML mappings dynamically via a custom driver.

Pádraic Brady has posted a two part look at a service discovery process as it pertains to things like OpenID via Yadis.

From part one:

This first entry is an examination of Yadis, a Specification which is relied upon by OpenID. Of course Yadis is a topic of its own, since it is also used by Light-Weight Identity (LID), sxip Identity, and mIDm. You can bet more will join in once Yadis becomes more firmly established.

In this first part, he talks about what Yadis is, how it can help with service discovery, and how it would follow a "breadcrumb trail" to get to the information it needs (like getting the actual Yadi slocation from the initial OpenID request).

From part two:

After all this fuss and running about, it's easy to miss the point of Yadis - getting that final Yadis XRD document that describes the Services associated with a given ID.

Part two looks more at working with the Yadis Resource Descriptor information to grap the Type information out of it for the actual locations you'll needed. He also links to some more information on the Yadis specification in PDF form.

Pádraic Brady has posted a two part look at a service discovery process as it pertains to things like OpenID via Yadis.

From part one:

This first entry is an examination of Yadis, a Specification which is relied upon by OpenID. Of course Yadis is a topic of its own, since it is also used by Light-Weight Identity (LID), sxip Identity, and mIDm. You can bet more will join in once Yadis becomes more firmly established.

In this first part, he talks about what Yadis is, how it can help with service discovery, and how it would follow a "breadcrumb trail" to get to the information it needs (like getting the actual Yadi slocation from the initial OpenID request).

From part two:

After all this fuss and running about, it's easy to miss the point of Yadis - getting that final Yadis XRD document that describes the Services associated with a given ID.

Part two looks more at working with the Yadis Resource Descriptor information to grap the Type information out of it for the actual locations you'll needed. He also links to some more information on the Yadis specification in PDF form.