In an effort to dispel some of the rumors and myths around the CakePHP framework (as presented most recently by a different blogger) Chris Hartjes has made a new "mythbuster" post to his blog today with a rebuttal to the points from the other article.
I ran across an article comparing CakePHP and Symfony and found that the writer had a number of preconceived ideas about CakePHP. These same ideas keep popping up everywhere, used by people looking to get their hate on about CakePHP. I sent a very well-reasoned email to the writer clearing up some of those misconceptions [...] So, in the interest of clarifying things about CakePHP I thought I would share that email, slightly rewritten for this blog posting, but the content is roughly the same.
The post/email covers a few different topics some might have misconceptions about concerning the framework:
Lack of Documentation
Scaffolding
Models are tied to controllers in a 1:1 relationship
Cake's Ajax and Javascript helpers do not support graceful degradation
In looking to test his fputscsv functionality, David Otton found a simple way to measure its performance by using streams.
Then I realised I could use PHP's (fairly) new IO streams to dump the function's output to a temporary buffer, and read it back in for comparison. Not perfect, but it removes concerns about file mutexes, permissions, unique filenames, etc. and speeds up the tests, as they never touch disc.
He uses a custom stream and points it to php://memory to store and read the data from. Code is included in the post as well as example usage. It runs an assert that the value pushed into another memory chunk is the same as the first one (ensuring that the results of his fputcsv calls are valid).
In this new post to his blog Chris Hartjes suggests a new way to judge frameworks - how easy they make it to write unit tests against them and their resulting applications.
As a project for work gets ready for an alpha release, I've managed to eliminate all the serious bugs and now have some time for what should've been part of the project from the beginning: writing tests. [...] Since I'm using Code Igniter instead of CakePHP for this project (did I mention that I inherited the project and couldn't switch?) I started looking into the culture of testing surrounding Code Igniter. It's weaker than a newborn baby.
He tried to find anything he could use to write tests against the CodeIgniter application and finding fooStack as an easy to use tool for the job. This was what made him wonder how other frameworks stack up in the "has good unit testing functionality" category. He briefly covers four of them - CodeIgniter, Zend Framework, CakePHP and Symfony.
So now when you start comparing frameworks to each other, I think it's important you also consider how much effort has gone into creating tests for the core functionality of that framework. A well tested framework should mean far less surprises when using it.
Symfony developers out there will be happy to know that, since the release of symfony 1.1, writing unit tests for your models has been made even easier.
Writing unit tests for your Propel or Doctrine model is much more easier as of symfony 1.1. In this tutorial, you will learn some great tips and best practices to write better tests for your models.
The tutorial walks you through the creating of a simple test - evaluating a few criteria for the database contents. The entire thing is contained inside of YML files and is easily run via the sfConfig and integrated Propel functionality.
In a new post to his blog Matthew Weier O'Phinney talks about using the Zend_Test component of the Zend Framework to set up test suites on your application.
Testing and test automation should be easy and the complex approach is overkill for most of our applications. Fortunately, PHPUnit offers some other methods that make doing so relatively simple. The easiest method is to use an XML configuration file.
He includes a basic XML config file for a "My Test Suite" setup defining the application's directory and where to log the end report to. This simple PHPUnit configuration can be used with the "phpunit" command line binary to auto-configure all you'll need for the testing. Matthew also includes the code for a sample TestHelper you can drop right into the app to help set up your environment correctly when testing is needed.
Mike Naberezny has posted about some improvements that were made to the PHPUnit testing software lately (support for TestNG-style groupings) and how, with a few of his own suggestions it was made a bit more flexible.
At my company, we typically organize our test case classes into high-level groups such as unit and functional. Method-level group annotations are inconvenient for us because we'd need to annotate every method of every test case class.
He includes an example of their use - commenting a testing class and running it through the phpunit command line tool with a call to the testing group's name.
On the Ibuildings blog today Lorenzo Albertontakes a look at the Zend Framework, specifically as to how it can mimic regular HTTP calls with the built-in components.
One of the unit testing best practices suggests to break dependencies, so you can test each component separately. The first problem that arises when you want to test controllers might be having a tighter control over the HTTP Request and Response objects.
This problem is overcome with the Zend_Test_PHPUnit_ControllerTestCase. The second problem it with calls to external resources (like models/databases or web services). This is the prime focus of the post and seceral blocks of code are included to make a class to emulate the HTTP responses you might get back from the service.
In this new post to his blog today, Matthew Weier O'Phinney mentions the death of PHP4 and (the main focus) gives a preview of what's to come in the next version of the Zend Framework (1.6.0).
I'm celebrating [the death of PHP4] with the second release candidate of Zend Framework 1.6.0, which should drop today. There are a ton of new features available that I'm really excited about. I'm not going to go into implementation details here, but instead catalogue some of the larger and more interesting changes that are part of the release.
He mentions the Dojo integration, updates to the unit testing infrastructure, captcha support in the Zend_Form component, Firebug support and included pagination functionality. You can grab this preview release from the downloads page on the Zend Framework website.
Take a hint from Maarten Manders when renaming and moving around your unit testing order:
It's absolutely amazing how much you can mess up unit tests just by changing their order! (Trevi_* comes after Tilllate_*) Everyone knows that tests are supposed to be independent. But we all know how it is.
He asks for recommendations on what to do to help the situation. Comments on the post (including ones from Lukas Smith and Sebastian Bergmann) mention using PHPT, a new version of PHPUnit that will do just what he wants and whether or not to use Singletons.
