TAG | Unit Tests
Imagine you’re a business owner. You know what you want to get developed, you have the budget for it and you know when you need to see a result. You have someone to manage your development team (call him the product owner if you like) and the team seems skilled.
Now what do you need unit tests for?
Actually I started this blog a long time ago only to teach myself test driven development – hence the name. I know all the good reasons why I should’ve written unit tests first.
However I soon discovered that unit testing simply didn’t work out for me.
I don’t know who is responsible for having the first session start at 9h30 on a Saturday and after a GitHub night out but I’m happy not to have to take that slot.
Today is the last day of PHPDay in Italy. Yesterday was great fun and today will be just as good I reckon.
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..
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…)
For a while I’ve been toying with the idea to set up a fully automated continuous deployment process for my symfony plugins. You can think of continuous deployment as a continuous integration process with automated deployment.
I just didn’t come round to do it as I couldn’t find the time so far. But then I read this article by Toni Schneider about CD at wordpress.com and it got me hooked again.
So I thought lets write down what it takes for a start.
Usually the answer is a misconfiguration but sometimes of course they found one of the bugs I involuntarily put in the code.
In these cases I have to get down at the code level and try to fix it. This is how I usually do it.
An just to make sure there are no misunderstandings: I am not about to question TDD!
I am merely asking for help to find my way to do it properly..