On PHPMaster.com today there's a new article with some thoughts of a pragmatic tester - some thoughts from Michael Bodnarchuk about both unit and functional testing.

Here’s how it usually plays out: the developer thinks, “I need to do unit tests, and I should use PHPUnit because it’s a standard. I don’t know much about it, though.” Then he visits the PHPUnit site and reads the first chapter of the documentation, then the second, then the third… and is left scratching his head.

[...] Maybe something similar happened to you. Maybe not. But you really should know what to test and how to test it. Such knowledge comes from experience, so in this article I’ll share some of my experience with unit testing.

The article's not so much an introduction to unit testing as it is some of the experiences he's had around testing his applications both at the code level and from a functional perspective. He also mentions some alternatives to the standard PHPUnit testing like Atoum and EnhancePHP.

In you've been looking for a good, inspirational book to get you motivated as a programmer, Lorna Mitchell has a suggestion for you - The Passionate Programmer.

The Passionate Programmer contains a really insightful mix of advice, it manages to tell developers how to "be", without being preachy or patronising. There are some great stories in there, but mostly it talks about how to frame your thinking such that you can't help succeeding.

She notes that the pieces of advice in the book make for a good, engaging read and that can give the reader some directions to move to better themselves and their career. Her personal favorite section dealt with mentors/mentoring and how we as developers should constantly be both - always providing the "younger" generations the input they need while looking to the leaders of our communities to grow even more.

On the Test.ical.ly blog there's a recent post asking about good software architecture and how you could define it simply without having to muck around with all of the details it tends to conjure up.

What is a good architecture and why are there apparently two opposing trenches supporting quality on the one side and speed of development on the other side? After having had enough time to think about this whilst flying to Spain I came to the conclusion that Nils question whether it would be better to start quick and dirty to fail cheap in case the project is a looser or to stick to a clean and solid architecture and spend more time and money. Does quick always have to be dirty, clean always have to be slow, is dirty always quicker?

He suggests that "good architecture" and "quick and dirty" are the two opposite ends of the same spectrum. Instead, he suggests that a pragmatic approach is the best - focusing on what needs to be done rather that how to get there. Also by applying the "don't fix it if it's not broken" mentality to current methods and technologies, you can save a lot of hassle in the long run.