Thanks to Tim Ross who sent me this link to some code written by Roy Osherove that helps you write unit tests that involve multiple threads.

I haven't tried it, but from his blog post, I think whatb it does is ensure that your threads all finish before your test does.

I've been getting a good deal of encouragement to talk about multithreaded programming some more, as it seems to be an area of great technical interest to many of you out there in developerland.

It's also quite obviously an area of some considerable pain...

I want to talk about two specific kinds of things that can go wrong when two or more threads of execution start interacting with the same data and objects:

We all know the drill. The project deadline is looming. The schedule is slipping. The budget is straining.

What's the thin end of the wedge? Quality.

When teams are being driven by fear of failure (to appear to meet arbitrary deadlines), they do silly things. Mostly they stop taking care over the quality of the code they're writing and just start hacking out crap. Which always turns out to be a false economy.

Because FlexMock and RubyCocoa disagree about the use of method_missing, you need to use flexmock as follows:flexmock(SomeSubclassOfNSObject)If the method you want to mock isn’t already defined on SomeSubclassOfNSObject, you have to define it before mocking it:class Watcher < OSX::NSObject def observeValueForKeyPath_ofObject_change_context( [...]

While reading Tim Harford's excellent book on economics, The Logic of Life, I found this quote from Adam Smith:

"The man whose whole life is spent on performing a few simple operations ... has no occasion to exert his understanding or to exercise his his invention in finding out expedients for removing difficulties which never occur. He ... generally becomes as stupid and ignorant as it is possible for a human creature to become."

This is why it's important, I think, to drop the idea that it's a good idea to guide (or just as bad, to train) a tester with a thick book of specific steps to follow. We don't teach people to drive that way. People don't learn much when they're disengaged with the decisions about their processes and their learning.

Throughput and velocity are ways of measuring how fast a team can do work. Knowing how fast a team is going allows the team and their stakeholders to know when something is going to be done.

What is Velocity

Velocity (http://www.extremeprogramming.org/rules/velocity.html) is a commonly used metric for teams using Extreme Programming or Scrum as their guiding principles for software development. Velocity is a unit-less measure that tells the team how much work they should take on each iteration or sprint.

An O’Reilly book on web security testing is about to be released. I was a previewer for the book and have been reading chunks of the book these past months. The book is highly readable and packed with ideas. I learned a lot previewing the copy and chatting and emailing with Paco Hope and Ben Walther. See O’Reilly. Cheers to Ben and Paco.

Here’s a look at the table of contents -