TAG | phpUnit
Yesterday I was working on some PHPUnit test cases and couldn’t get two of them to work as I wanted them to.
The answer was actually in the documentation and taught me not only about why it wasn’t working but also a lesson about documentation.
Recently working on ImageTransform I decided to do a big refactoring during which I had to move around a lot of classes as I reorganised the folder structure. This of course includes changing a lot of namespaces.
Usually something like this would drag a lot of work behind. Unless..
But I’m not yet sure what is the best approach to use this loader.
What I called my “little experience” during the last two days is actually the attempt to rewrite the image manipulation library ImageTransform by Stuart Lowes, which itself is the attempt to turn the symfony plugin sfImageTransformPlugin into a standalone library (unfinished). It’s not at all official and it might be binned again at some point. Until I know that it stays my personal toy.
One of the goals I set myself is to make the code as decoupled as possible and to prove that I try to maintain a high unit test coverage.
I mentioned yesterday that I am toying around with some little library code that is completely standalone.
As I plan on using this code in a Symfony2 project later I chose to finally switch to PHP 5.3 including namespaces.
And as soon as I started I needed to decide on a naming convention for my classes, a directory structure, a convention to name my PHPUnit tests and a way to autoload these classes to avoid require statements.
Over the weekend I started writing some code just to try out a few ideas. Over the last four years I have been writing a lot of code but best of it was related to symfony. So this was a nice situation to start something from scratch.
Of course I experienced a lot during the past and also did I learn a lot from participating – actively and passively – in the symfony community. The most important fact I learned is that the key principle of programming that decides about if your code gets manageable is: Separation of Concerns.
And with my small experiment I also learned that following it reduces the time you spend writing unit tests! (more…)
The symfony day 2010 in Cologne was on this weekend and it had some awesome talks. Certainly I had a lot of fun as it was my first conference as a speaker. But I think I wasn’t the only one enjoying hi time there.
For those unfortunate of you who couldn’t attend to it here’s a wrap-up.
Today just a short notice while I am preparing for the upcoming symfony day 2010 in Cologne.
Sebastian Bergmann just recently released a new minor version of PHPUnit 3.5 during the PHP Unconference in Hamburg.
Get it while it’s hot as it’s faster and more complete and also the documentation has even more details added to it!
It has been broken down into several standalone components which promise for less maintenance effort thus faster development.
It also eases writing test cases a lot as from now on you no longer have to require anything as long as PHPUnit is in your include paths.
PHPUnit 3.5 just feels good!
It is rarely the case that your unit tests actually test your database. It is however not so rare that the code your unit test tries to cover needs a database connection of some sorts.
In symfony 1.x you will find quite some tightly coupled code. Together with Doctrines (1.x) implementation of the active record pattern you will get a lot of exceptions complaining about no open database connection.
So if your tests need a database connection how should you do that?
Apparently this is considered a best practice however I came to thing quite the opposite.