Although most modern literature agrees that testing is essential for successful software projects, testing has to be done right. Several bad habits can be identified that not only negatively affect testing performance, but also reduce your development speed. One of the first mistakes people make when they first discover testing is trying to reach 100% code coverage. I was no exception.
Unit testing can be a blessing and curse at the same time. Once you start doing
it on a regular basis, it can become an addiction. You test everything, you feel
the satisfaction of 110% test coverage giving you confidence in your code. But
after a while, testing suddenly seems to slow you down. Every time you make a
change in your code you have to adapt several unrelated tests. Adding a
<ul>-tag to your template becomes a matter of minutes, rather than seconds.
And, worst of all, your test suite is slow.
The "default" context does not exist.
Is there any symfony developer out there who never stumbled upon this dreadful error message? I doubt it. Recently, a lot of posts have been made on the user mailing list asking for explanations and fixes. A quick search on Google for the exact phrase even returns 480 results!
The reason for this error is quite simple though: It's because you used
sfContext::getInstance(). And you should never do that.
Unit testing is a very important task of professional, scalable software development. Many tools exist to support unit testing in one or another way. All tools come with advantages and drawbacks. One of the best known test frameworks in the PHP world is PHPUnit. With the release of symfony, Fabien Potencier released another new testing framework for PHP: lime. The biggest advantage of lime over PHPUnit surely is the conciseness of the written test code. There are several disadvantages as well, which include bad test encapsulation due to the lack of support for fixture setup and teardown, and missing support for mock object generation.
Today I will briefly speak about the advantages of both frameworks, and how they can be combined to result in a slicker, powerful testing framework. I will show you how easy testing really can be! And you will be able to try it out, because all the required code has already been released in sfLimeExtraPlugin.
This guest post was written by Klemens Ullmann-Marx, a web developer in Vienna and founder of the company ull.at.
In this tutorial we will set up Xdebug to profile your application and then we'll analyse the output with KCachegrind.
Keeping all parts of a website consistent is one of the most time consuming tasks of a web designer. Spending this time is worth doing, because the more consistent the look and feel of your website is, the more professional it appears to its users.
I will show you today how symfony could help you keeping all of your forms consistent with very little work left for you to do.
Today I want to follow up on my last post about improving the forms in symfony. David Hermann wrote a quite interesting reply on his blog. I want to take some of his ideas and enhance them even further. The goal is to be able to reuse as much code as possible when creating applications with lots of different forms.
This post will be different though. While I only made assumptions in my last post without any code verifying that my ideas are implementable, I do have a prototype implementation now.