Hi Petr,

I’m answering your questions generally first, then I’ll write more comments (in a separate post) as I inspect the source code.

As a temporary solution I’ve made a bool operator== (const RequestHeader &header1, const RequestHeader &header2) function in the Http namespace which implements it. My question is - should I implement it in the Http::RequestHeader and Http::ResponseHeader classes or is there any other solution I should pick?

The short answer is yes! If you pass an object by value or by const reference then the object must provide an operator==. The longer answer is that CalitkoMocks assumes such objects are ValueObject in which case they could be compared when verifying the expectations. An expectation is the call of a mock object (along with parameter values). CalitkoMocks will know the expectation was fulfilled if the function is not only called, but is called with the exact (expected) parameters.

Http::Header and its derived classes should implement a Value Object, so we should provide operator==(). The operator()== implementation compating the raw representation of the Header objects should actually work for all Header variants.

Second question is related to the TrackerRequestSession. How can (should) I test (implement) failures (reactions to failures)? For example if a request header cannot be sent (connection failed or something) - httpRequestSession->get() fails. Should I made these functions returning bool instead of void or there is some other way? I was thinking about adding some member functions like requestWasNotSent() (I think I’ve seen it somewhere), which gets called if a request transfer fails, but I don’t know where to “put” it… HttpRequestSession doesn’t know anything about TrackerRequestSessionStatus.

get() will most likely not always be able to complete synchronously. I don’t think get() would ever fail actually, not synchronously at least, so void is OK. If the Transport gets disconnected, the session would send sessionClosed(). If the received response could not be correctly parsed, sessionClosed() could be sent as well. At first I would not try to differentiate between the different kinds of errors - the user (code) would generally only care to know whether the get() worked at all.

We can never be 100% certain whether the request was actually sent and not at all sure whether it has been received. The Http::RequestHeader object could be buffered in HttpRequestSession, but it could also be buffered in Transport, or it could be buffered by the OS, or some router on the Internet. Again, I don’t think that the user of the class would ever need to know much of the error details - it would generally care only of the end result - response was received or not.

I hope that helps at first a little. I’ll post again later with further comments regarding the code itself!

Regards,

Peter