Unit Tests Are Not About Testing

See Unit Tests Are Not About Testing at its new home on bradley-holt.com.

I had the suspicion for a while but it didn't become clear to me until recently that unit testing really is not about testing. Sure, you are writing tests and there is certainly value in having "tests." However, the real value of unit testing becomes evident when you stop thinking of it in terms of testing. If it's not about testing then what is it about? Unit testing is really about defining behavior. Enter Behavior Driven Development (BDD):

It is not too surprising that it takes apprentice TDD [test-driven development] practitioners a while to realize that TDD is not about testing when all of the nomenclature surrounding it is described in terms of testing.

The aim of Behaviour Driven Development (BDD) is to address this shortcoming. By using terminology focused on the behavioural aspects of the system rather than testing, BDD attempts to help direct developers towards a focus on the real value to be found in TDD at its most successful.

If you're using PHPUnit then check out the Behaviour-Driven Development chapter for more details on how you can use this approach.

Models of Software Acceptance

See Models of Software Acceptance at its new home on bradley-holt.com.

A little while ago I read Richard P. Gabriel's talk on Models of Software Acceptance [PDF]. I couldn't find a date on this talk but I think it's rather old, at least in terms of technology. However, there is very little in there that seems dated and much of it is very relevant today. From the introduction:

Building business success on technology is not easy—myths abound based on common sense, tales told by those who have won, analogies to things like evolution, and appeals to inventiveness and innovation. When we look closely at how technology is accepted and how success is built on it, the picture is quite different, and the process of acceptance is both lengthy and unpredictable. In this talk we’ll look at the myths and the realities, we’ll look at many specific examples, and we’ll conjecture a set of principles that might work.

Those of us who use and build technology every day often don't give much thought to technology acceptance. We're always trying out the newest and latest technology and are frustrated that others aren't keeping up with our efforts to bring technology forward. We're often surprised by what technology does and does not get accepted by the mainstream. We wait impatiently for the rest of the world to catch up with us. A common meme on the popular technology news website Slashdot is, "Where's my flying car?" Most people don't want a flying car, at least not yet.

Many of the interesting innovation opportunities are in technology acceptance. Sure, Google has some of the most advanced technology around but how have they lost out to Facebook over Orkut and to Twitter over Jaiku? Both Orkut and Jaiku are owned by Google but Google's likely superior technology platform does not necessarily equate to superior user acceptance.

The information in Gabriel's talk is great news for startups and entrepreneurs. Focus on technology that is several years old, keep your design simple, and find a niche opportunity where a larger competitor can't beat you at gambler’s ruin. Read the full talk [PDF] for all the details.

Social Coding

See Social Coding at its new home on bradley-holt.com.

My first real introduction to Git and GitHub was at last year's ZendCon. I've been using Subversion, a centralized revision control tool, for a few years now and it has changed the way I work. For example, I think in terms of changesets or "commits" that fix a defect, make an enhancement or complete a task in my codebase. It's a workflow that has served me well.

I'd heard about distributed revision control tools before last year's ZendCon. I thought it was a neat idea but didn't really get what the advantage was over a centralized tool like Subversion. The folks from GitHub had a vendor booth so I thought I'd ask them why Git was better than Subversion. I forget exactly what they said (probably something about how branching and merging is so much easier in Git) but whatever it was it definitely made me consider trying Git.

The GitHub folks were wearing t-shirts that said, "fork you" and explained that on GitHub they encourage projects to fork. Typically in free/open source projects forking is considered a bad thing. It usually signifies some breakdown in the community when one project forks from another. However, with Git and GitHub it's really easy to "clone" a project's repository, hack away at some changes, and then "push" (or have "pulled") your changes back to the repository you originally cloned. Git makes branching, cloning, pushing/pulling, and merging very easy and GitHub provides a place to host your repositories making this interaction with other people's repositories very simple.

GitHub's tagline is "social coding." With distributed revision control each developer gets his or her own project repository. If your repository is public then anyone can come along and make a clone of it giving themselves their own copy of your project to work on. Assuming their clone is also public, you can track their changes and decide if you want to pull in work they've done. If you find yourself collaborating a lot with a particular person that you trust, you can give them the ability to push to your repository. With Git this actually scales to projects with lots of contributors. This may seem chaotic, pushing and pulling changes to and from decentralized repositories, but it's actually a great way to encourage ad hoc collaboration.

If you want to learn more about Git you can read the Git Community Book, Pragmatic Version Control Using Git or the Pro Git Book. One last thing: if you're currently a Subversion user then forget everything you know about how Subversion works. While a lot of the commands may be similar to Subversion and there's a way to integrate with Subversion (git-svn), Git is fundamentally very different than Subversion. If you try and equate the two you'll most likely end up confused!