Who are you? The new number 2… Who is number 1?
Looks like Roy Osherove is making waves with his comments about MVP information hoarding… Having been in the position of being a developer searching for scraps of information on a MS technology that doesn’t appear to be documented as well as it could be I know where he’s coming from.
Sometimes, during the early stages of understanding, I find that I can google for answers better than I can phrase questions.
I want some new and interesting blogs to read, so leave a comment if you have any suggestions. I subscribe to quite a few (opml file here) but I’m a bit tired of the Microsoft Employee Bleating Edge Blog stuff… Ideally I’m looking for technical blogs with a “working programmer” slant. It would be nice if they were biased towards C++ but I don’t really care.
I think these guys are good, so more like this would be nice:
*There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
C. A. R. Hoare* From Joel’s discussion board…
During the recent library adjustments the main aim was to add tests. As we write tests we create lots of mock objects. Our libraries are dependant on each other, as libraries tend to be, and this means that often a library uses an interface from another library… When it comes to test the dependant library it’s often handy to be able to use the mock object that you created to test the library that you’re dependant on… If you see what I mean… The, slightly labored, point being, it’s important where you keep your mock objects…
The refactoring and testing of The Server Framework code has gone pretty well. It’s not complete but at least we have some tests now and the code is broken down into slightly more cohesive lumps…
Once the tests were in place and working we had to integrate the changes with the various projects that use the library; each of these projects pull the library in slightly different directions so the integration took a while.
I get quite a bit of feedback about the socket server code but I don’t really know what people are using it for. So, if you can, leave a comment or drop me a mail and tell me.
After breaking the socket server into more manageable chunks I started writing the tests. CAsyncSocketConnectionManager is pretty easy to test, it only has one public function; Connect().
So, what exactly do these tests look like?
I don’t use a unit testing framework at present, I haven’t found a need. Whilst NUnit and JUnit are great I don’t feel that the C++ version adds much as C++ doesn’t support reflection and that’s where these frameworks really seem to win.
I’m writing tests for some code. I have a function that I’m testing that looks something like this:
bool CAsyncSocket::Read(bool throwOnFailure = false);
If C++ allowed us to overload a function call based on return type then we wouldn’t need the horrible throwOnFailure wart and the compiler could pick the right version depending on if we try to use the return value or not… So a call like this: bool ok = pSocket->Read(); would return errors and a call like this: pSocket->Read(); would throw exceptions…
So I have some time on my hands and I’ve decided that The Server Framework code could do with some tests but before I can do that I need to refactor because the code was written before I became test infected and, well, it’s not as good as it could be…
Step one, as always, is to work on decoupling the code to the point that it’s easy to test. This generally involves breaking the code apart into more cohesive chunks and then writing tests for the chunks.
I have a couple of days to myself. We’ve just shipped some code to a client a couple of days ahead of schedule and we’re waiting to recieve a purchase order from another client so I find myself without any client work to do. I’ve decided to try and refactor The Server Framework code that we’re using a lot right now. Whilst working on the code that we’ve just shipped I realised that the new code I was writing was much easier to test than the socket server library that formed a major part of the project, so now that I have some time I’m going to try and rectify that.
