Source Code

Previously on Practical Testing: The last entry ended with us having two tests, both of which were in need to a good refactoring. The second test had uncovered an unexpected bug… This time around we’ll refactor the tests, fix the bug and finally write the test for the tick count wrap bug… Our new test breaks because the CCallbackTimer is failing to keep the timers in the correct order in its queue.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 4. We have a test for SetTimer() but it’s not as robust as we’d like. The problem is that the class under test is runs its own thread which reacts based on time and this makes our testing harder and less predictable. What’s more it actually makes testing for our known bug practically impossible; to test for our bug we’d have to have a test which called GetTickCount() to determine the current value and which then slept so that it could execute the test at the point when the counter rolled over to 0.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 3. Last time we wrote the first test. It doesn’t test much, but it proves we can test. Now we’ll write a real test for real functionality and along the way we’ll start to deal with some of the issues that come up when you’re trying to test multi-threaded code.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 2. In part 1 I introduced the code that we’re going to write a test for. Now we’ll move towards the all important first test. The first test is, in my opinion, vitally important; the first test proves that you can build a test harness that can create the object. This sounds easy, but try picking a class from your current project at random and writing a test that constructs an instance of that class.

I’m writing some blog entries that show how to write tests for non trivial pieces of code. This is part 1. The code that we’re going to test is CCallbackTimer. This is a class that lives in our Win32Tools library. It’s used by users of our SocketTools library. The class provides a very light-weight timer manager that gets around the various issues we had with using standard Win32 timers. The timer is designed to be used in vast quantities.

This morning I decided to investigate the Windows XP SP1 Bluetooth support. I played with the BluetoothXXXX and quickly became disapointed. I then moved on to looking at how to access the Bluetooth hardware using Winsock and decided that is a much better route to take… The Bluetooth API that lives in Irprops.cpl appears to be the easy way in to Bluetooth. The API itself has an ‘interesting’ design, but I can kinda understand why it looks like it does.

The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com. I’ve updated the code for two more of the socket server articles. More merging, project file updating, and testing… [NOTE: This code leaks when adjusted to build with Visual Studio 2005. This seems to be due to a bug in VS2005’s STL. See here for a workaround.

The latest release of the free version of my asynchronous, windows, IOCP based, socket server framework can now be obtained from here at ServerFramework.com. For some time I’ve been promising to update the socket server articles to use the latest version of my code. Today I finally updated the code for the first article. I’m going to update the article itself soon, but in the meantime I’m posting the new code here.

OpenSSL is an open source implementation of the SSL and TLS protocols. Unfortunately it doesn’t play well with windows style asynchronous sockets. This article - previously published in Windows Developer Magazine and now available on the Dr. Dobbs site - provides a simple connector that enables you to use OpenSSL asynchronously. Note: If you need high performance SSL over TCP/IP then this is available as an optional part of The Server Framework; see here for details.

Sometimes it would be nice to be able to use a simple C++ object as a sink for Connection Point notifications. This article shows you how. Sinking connection points in C++ objects. Many COM objects provide events to their clients by means on Connection Points. A Connection Point is a generalised method of allowing clients to register a COM interface so that the object can notify them of things that they may be interested in.