The Codeception blog has recent post they've written up talking about writing better tests for your application and the difference between expectation and implementation as it relates back to meaningful tests.

What makes a meaningful test? This question should always be asked. No matter we write your tests first or tests after, they may stay in a project for years and it is pretty important them to test the things that really matters. Badly written tests can slow us down by constantly failing on each implementation change, and such tests can be written no matter you follow TDD or not. The idea of a test is to ensure that software works and not to freeze it at specific point.

Such situation happens when a test is bound to implementation details. [...] But how to understand what is stable and what is not? We need to use interfaces. Not that one which is written as interface keyword in PHP but a general term: User Interface, API. And that’s what makes unit testing and browser testing similar: we always need to rely on public interfaces for a test.

They give an example of a test that's "bound to implementation details" from the Magento codebase that relies on a specific function implementation (the "makdir" method). This function is a part of the Symfony functionality, not Magento, and what might happen if things change in your application. They note that the main difference is testing for the result versus testing for the behavior of the functionality. The tutorial wraps up by suggesting that the only testing that should be done is on public, well-defined interfaces that are not as subject to change and not copying logic into tests.

The PHP Roundtable podcast has posted their latest episode, part two in a series looking at semantic versioning, open source support expectations and licensing. This new episode features guests Colin O'Dell and Chris Tankersly.

Part 2 of an on-going series on open source. We discuss a number of open source topics including what the expectations are for support of an open source project. We also discuss how to use SemVer to successfully maintain an open source package and what we can do when SemVer is not an option. And finally we take a look at licensing and discuss why we need to be concerned with it.

You can listen to this latest episode by checking out the video of the live recording, coming in at about 1 hour. If you enjoy the show, be sure to subscribe to their feed to get the latest updates on when new episodes are available.