Hi Petr,

I just pushed a revision based on your latest with the tests reworked.

I think the tests are a good demonstration for the “Tell, Don’t Ask” principle. I’ve removed the testResponseReturning() test which called the response() function to ask what has been read:

	void testResponseReturning()
	{
		testHandleResponseSucceeded();
		call (session->response())
		.willReturn(trackerResponse);
	}

Instead, the tracker response is sent to the status listener once it has been read (comments snipped):

void testRecieveResponseHttp200()
	{
		stateWaitingForResponse();
		call (session->handleResponse (responseHeader200))
		.returns();
		call (session->handleMessageBody (trackerResponseBytes))
			.willCall (sessionStatus->receivedTrackerResponse (trackerResponse))
			.returns()
		.returns();
		}
	}

I didn’t want to write more tests first because I actually couldn’t think of many and second because I thought it would be better for you to try first!

I hope you also start to feel the power of testing with Mock Objects - you can express your design ideas in code without even writing implementation! What I’d suggest you though (that’s the TDD philosophy) is to write a single test that fails, make it pass, then refactor both the test and the implementation if needed. The test and the implementation would very often be “stable” only after a few iterations. Unless there is a compelling reason to do so (you need to get a better overview of the problem, or you are certain you can do it right), do not write too many tests at once! Considered that as a guideline rather then a general rule though! Your experience will be able to tell you what is appropriate in which cases.

I’m looking forward to seeing your new tests and comments!

Good night,

Peter