/* Rambling comments... */

Practical Testing: 28 - Finishing the timer wheel Posted by Len at 4 Aug 2010 12:54 PM
Previously on "Practical Testing"... I'm writing a timer wheel which matches the interface used by my timer queue. This new implementation is designed for a particular usage scenario with the intention of trading space for speed and improving performance of...

Practical Testing: 27 - Fixing things... Posted by Len at 3 Aug 2010 05:53 PM
Previously on "Practical Testing"... To deal with some specific usage scenarios of a piece of general purpose code I'm in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in...

Practical Testing: 26 - More functionality, more refactoring and a new bug Posted by Len at 23 Jul 2010 09:56 AM
Previously on "Practical Testing"... To deal with some specific usage scenarios of a piece of general purpose code I'm in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in...

Practical Testing: 25 - Nothing is free Posted by Len at 21 Jul 2010 02:13 PM
I'm in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. The idea being that for certain specific usage scenarios the timer wheel will perform...

Practical Testing: 24 - Removing test duplication Posted by Len at 20 Jul 2010 02:53 PM
The most recent articles in the "Practical Testing" series have been discussing the performance of the timer queue that we have built. Once I had got some new, optional, performance tests in place to measure what we were trying to...

Practical Testing: 23 - Another new approach: timer wheels Posted by Len at 19 Jul 2010 09:01 AM
The most recent articles in the "Practical Testing" series have been discussing the performance of the timer queue that we have built. As I hinted when I first brought up the performance issues, the particular use case that I have...

Practical Testing: 22 - Performance: Some you win... Posted by Len at 15 Jul 2010 09:29 PM
The previous article in the "Practical Testing" series set things up so that we can measure the performance of the code under test with the intention of trying to improve performance for a specific set of use case scenarios. This...

Practical Testing: 21 - Looking at Performance and finding a leak Posted by Len at 15 Jul 2010 11:43 AM
Back in 2004, I wrote a series of articles called "Practical Testing" where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to...

Unit testing AVR assembly language Posted by Len at 23 Oct 2009 11:28 AM
My "hobby project" is going well but the AVR assembly language that I'm writing has now got complex enough for me to really miss not having some form of unit testing framework in place. So I decided to remedy that...

Testing blocking calls Posted by Len at 6 Aug 2009 02:02 PM
I'm developing the simple client server protocol code that I'm harvesting in a test driven manner. Although the code exists, as such, and I'm harvesting it rather than inventing it from scratch the harvesting is taking the "best" ideas from...

Asserts and testing Posted by Len at 10 Feb 2009 09:53 AM
Miško Hevery over at the Google Testing Blog has a few things to say about Asserts and testing. He's against asserts, specifically ones which perform null checks, as they get in the way of testing. Whilst I agree with his...

Practical Testing: 20 - Mind the gap Posted by Len at 12 Aug 2008 12:44 PM
Back in 2004, I wrote a series of articles called "Practical Testing" where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to...

Writing testable code Posted by Len at 7 Aug 2008 09:05 AM
There's a nice post by Miško Hevery over on the Google Testing Blog about Writing Testable Code. It pretty much sums up my views on testable code. Go read it!...

Practical Testing: 19 - Removing the duplicate code Posted by Len at 3 Aug 2008 09:28 PM
The code in the last two articles in the "Practical Testing" series have contained a considerable amount of duplication. This came about for a couple of reasons. Firstly part 17 was a bit rushed and secondly it was useful to...

Practical Testing: 18 - Removing the potential to deadlock Posted by Len at 2 Aug 2008 12:15 PM
Back in 2004, I wrote a series of articles called "Practical Testing" where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to...

Another ISO 8583 transaction server Posted by Len at 3 Jun 2008 01:11 PM
It has been a busy couple of weeks for me. I've been working on an ISO 8583 based transaction server for a client and I set myself some fairly tight deadlines. I actually developed the first version of the server...

More on the CLR startup change Posted by Len at 6 May 2008 03:37 PM
Last week I mentioned that some of my tests for my Win32 Debug API class had suddenly started failing. It seems that I was right and the changes are due to some .Net fixes that have been rolled out recently....

WOW64 Win32 DebugAPI CLR application startup change Posted by Len at 1 May 2008 04:43 PM
Back in October 2007 I sumarised my findings from getting my Win32 DebugAPI based debug engine working on x64. One of the strange things that I found at the time was this: When running a CLR app under the Win32...

What would I do?? Posted by Len at 15 Apr 2008 10:24 PM
There's an entry over on the Dr. Dobbs blog about testing and how you make sure that your tests are testing the right thing; effectively, who tests the test. There's a question at the end "What do you do?" and...

Practical Testing: 17 - A whole new approach Posted by Len at 9 Apr 2008 06:54 PM
The comments to my last practical testing entry got me thinking. The commenter who had located the bug in part 15, which was fixed in part 16, suggested a new approach to the problem and I've been investigating it. The...

Practical Testing: 16 - Fixing a timeout bug Posted by Len at 4 Apr 2008 10:28 AM
Back in 2004, I wrote a series of articles called "Practical Testing" where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to...

Bug in my debugger code, and hence also in TickShifter Posted by Len at 5 Mar 2007 05:52 AM
Back in April 2006 I posted a copy of TickShifter, see here for details. It seems that there was a bug in my Win32 debugger code on which TickShifter is built. The bug was that we failed to "forget about"...

Mock32, parameterize from below Posted by Len at 12 May 2006 07:07 AM
It's funny how potential product ideas beget other potential product ideas and the thing that you eventually end up with as a product for sale is often far from the original product idea and the code that you started to...

Tools, debug thyselves Posted by Len at 12 Apr 2006 08:31 AM
One of the first things that I tried to do with the latest release of my TickShifter tool was to run it on itself. Of course, that didn't work. There are several reasons why the tool might have had problems...

TickShifter v0.2 Posted by Len at 9 Apr 2006 09:49 PM
As I mentioned a while back, I've been working on adding rudimentary GUIs to my debugging and testing tools. In fact, both the deadlock detection tool and the time shifting tool are both functional enough for real world use but...

TickShifter v0.1 Posted by Len at 4 Apr 2006 04:47 PM
Well, I figure that I've written about these debug tools that I've been working on for long enough. The time has come to make one available for other people to use and abuse. Given that I hope to sell some...

Look back and shudder Posted by Len at 20 Jan 2006 07:29 PM
I'm currently investigating a memory leak in a complicated piece of multi-threaded code. Unfortunately the code doesn't have any unit tests and the leak only shows up reliably in the release build. Worse, I wrote the code and nobody has...

When your mocks are executable Posted by Len at 16 Jan 2006 01:12 PM
The size of the "units" that I test with my unit tests varies quite considerably. Usually I tend to work at the single class level; the test will provide mocks for the services that the class requires and the tests...

Implicit Interfaces Posted by Len at 7 Jan 2006 09:57 AM
ImplicitInterfaceImplementation - from Martin Fowler is an interesting piece where Martin suggests that it would be useful to be able to provide alternative implementations of a class's implicit interface. That is, given a class that does not inherit from an...

Panto season! Posted by Len at 21 Dec 2005 09:42 PM
In case you missed it the first time around... We're doing the old "assert is evil"/"Oh no it isn't" thing over at Ned Batchelder's place....

I think the weirdness was me Posted by Len at 17 Dec 2005 10:51 AM
A couple of days ago I mentioned that I was having some problems with loading symbols for a common controls dll. I'm now pretty sure that it was my problem, as usual, rather than someone elses. I've reworked my process...

DbgHelp weirdness Posted by Len at 14 Dec 2005 09:17 PM
I was using one of my home made debugging tools recently and it kept crashing :( I assumed it was something I was doing but I've eventually tracked it down to where I load the symbols for the loaded modules...

3 days with JMock Posted by Len at 9 Dec 2005 11:32 AM
As I mentioned last week, I'm currently doing some Java work with an investment banking client. This week I added JMock to their toolset. JMock is a dynamic mock object generation tool that works with JUnit to allow you to...

Testing Windows Services Posted by Len at 30 Nov 2005 10:38 AM
Mark Pearce writes about Debugging a .Net Windows Service from within the IDE. We do something similar with our C++ Windows services but, as you've probably come to expect from me, it's slightly more complicated than Mark's approach....

Kevin Barnes on TDD Posted by Len at 19 Nov 2005 03:10 PM
Kevin Barnes over at Code Craft has just written an interesting piece on TDD. In it he claims that "Excessive unit testing infrastructure hampers your practical ability to refactor things efficiently. People scream at me when I say this. Unit...

Controlling Time, Take 2 Posted by Len at 11 Nov 2005 10:20 AM
Recently I finished developing a high performance ISO-8583 financial transaction authorisation server for a client and whilst I was running the final black-box tests against the server I realised that these particular tests were dependant on the system date of...

Profilers and The Perils of Micro-Optimization Posted by Len at 9 Nov 2005 11:32 AM
Ian Griffiths has just written a nice piece on profiling .Net code and why the obvious things that people do are often very wrong: "Unfortunately, lots of developers just love to go off on micro-benchmarking exercises, where they write about...

What's your worst bug? Posted by Len at 8 Nov 2005 01:30 PM
"Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die;...

Windows TCP/IP Server Performance Posted by Len at 3 Nov 2005 12:18 PM
For the last week or so I've been working on measuring and improving the performance of our socket server framework. A long time ago I posted a version of this framework on CodeProject, I then updated it here and here...

Practical Testing: 15 - Testing payback Posted by Len at 1 Nov 2005 12:50 PM
Last year I wrote a series of articles called "Practical Testing" where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show...

Unit testing and accessing external systems Posted by Len at 22 Oct 2005 02:42 PM
There's a lot of talk about how unit tests shouldn't touch the network or the file system or databases whilst they're running. Michael Feathers even has a set of unit test "rules" (A Set of Unit Testing Rules) which go...

Printf debugging when you don't have a console Posted by Len at 11 Oct 2005 09:18 AM
There's a nice story over on "Bug Babble" about debugging a problem with a robot by using various sounds coming out of a speaker to determine where in the code the problem occurred: "Now the robot sounded like a modem...

Dependency Injection Posted by Len at 9 Oct 2005 11:07 PM
Jeremy D. Miller writes about The Dependency Injection Pattern; or what I've tended to call "Parameterise from above". He covers the various ways you can inject a dependency into a class rather than having the knowledge of the dependency hard...

Thoughts on testing COM objects Posted by Len at 16 Sep 2005 07:12 PM
Ben over at Code Circle is thinking about unit testing COM objects. I did quite a lot of this back in 2000 when I was working with an investment bank. The first thing you need to realise is that COM...

How refreshing Posted by Len at 1 Sep 2005 05:30 PM
One of the things that I've always been a bit unsure of is the claim by dynamic languages crowd that static typing buys us nothing as the unit tests solve the same problem. It's a nice idea but I'm a...

Setup and Teardown, reprise Posted by Len at 3 Aug 2005 07:40 AM
Roy adds a little fine tuning to Brian's advice about avoiding setup and teardown in unit tests. In summary; aim to minimise duplication in your test code......

Exploring the C++ Unit Testing Framework Jungle Posted by Len at 2 Aug 2005 08:14 AM
Exploring the C++ Unit Testing Framework Jungle over on Games from Within is a really good look at all of the C++ unit testing frameworks out there. It compares the following frameworks: * CppUnit * Boost.Test * CppUnitLite * NanoCppUnit...

Setup and TearDown considered harmful? Posted by Len at 27 Jul 2005 07:33 PM
I'm glad that Brian Button went to the trouble of writing this post and thinking through the implications of shared setup and teardown code in tests. I've been a bit concerned about some of my tests for a while now....

Unit testing for speed? Posted by Len at 26 Jul 2005 04:39 PM
Simon is thinking about using unit testing to help with performance testing. Whilst I've found it useful to use unit tests as very focussed ways to run a profiler on a selection of code I don't think it's a good...

My own legacy code Posted by Len at 20 Jul 2005 12:34 PM
I've just started work on an ISO8583 server for a client. I've done similar work for them in the past and the first thing that I did was to take the basic shell of the last server that I did...

Ok, Roy wins, I'm starting to see the advantage of mocks with expectations Posted by Len at 25 Jun 2005 11:34 AM
Last week I posted an entry about the simple, hand built, mocks that I use for testing in C++. Whilst I stand by my previous assertion that writing the mocks yourself gives you an further insight into your design from...

Easy interaction testing in C++ with Mocks that create logs Posted by Len at 17 Jun 2005 11:55 AM
My Unicode Byte Order Mark hassles yesterday were brought to light by one of my mock objects. It was the expected output log for the object that had been converted from UTF-16 to UTF-8 by CVS without asking... Whilst writing...

Practical Testing: 14 - Bitten by the handle reuse problem Posted by Len at 7 Mar 2005 01:53 PM
A long time ago, on Practical Testing: I mentioned that there was a small chance that the way that ResetTimer() operated could mean that you could pass in a handle that you no longer owned and affect someone else's timer...

Why you're missing the point if you use a framework to generate mock objects for you... Posted by Len at 17 Dec 2004 10:38 PM
Roy Osherove links to Mockpp a mock object framework for C++ and comments on how the framework is painful to use (and it looks like it was painful to write...) He concludes that he's getting on just fine writing his...

Hoisting test code into production Posted by Len at 1 Dec 2004 10:37 PM
A while ago I mentioned how I had hoisted a mock object up into production code because it only needed a few changes to make it usable as real code rather than just test code. This last week we've done this again...

The value of malleable systems Posted by Len at 1 Dec 2004 09:16 PM
We're almost at the end of our hand over phase now; my time on the project is almost over. The last couple of weeks have been interesting. We've been working towards a demo of the system and this seems to...

So much for testing Posted by Len at 20 Nov 2004 09:54 AM
My category-based RSS feeds stopped feeding through to Testing Reflections and Test Driven a couple of weeks ago. They had worked fine, and then they just stopped. I assumed that the problem was at their end; either they didn't think much of my testing posts or their feed polling software had some weirdness in it... But you know what assume does...

Looking back from near the end Posted by Len at 16 Nov 2004 11:06 PM
My current consulting gig is coming to an end. We've been in the hand over phase for a while now and I think it's slowly starting to work. Now seems like a good time to look back at what worked and what didn't...

Practical Testing: 13 - Missing functionality Posted by Len at 22 Oct 2004 08:54 AM
Previously, on Practical Testing: we added a multi-threaded version of our timer queue that manages timeouts automatically. This time we'll integrate our new timer queue into an application that uses the old version of the code and, along the way, discover some functionality that the original version requires but that the new version currently doesn't.

Measure twice, cut once Posted by Len at 12 Oct 2004 08:45 AM
I'm currently working on a small auction server for a client. It's a relatively simple server, messages come in, are validated and are then broadcast to interested parties and logged. Yesterday we shipped the first cut of the source to them and I was a bit concerned that our simple test app could thrash the server so easily. Admittedly the first cut of the code hadn't been tuned at all and the logging implementation was fairly Mickey Mouse but I was a little concerned. I woke this morning with a list of perf improvements to try. Some of them from my original design sketches and some new ones. Luckily I put the right one at the top of the list.

Practical Testing: 12 - Threading is orthogonal Posted by Len at 9 Oct 2004 10:51 PM
Previously, on Practical Testing: we finished our reworking on the code we were left with a simpler timer queue that passed all of our tests, but was single threaded and needed manual intervention from client code to manage timeouts. Today we'll add back the multi-threaded functionality so that the queue manages timeouts automatically.

11th October is Thanksgiving Day in Canada Posted by Len at 8 Oct 2004 05:08 PM
I've had an interesting week. I'm back with the Refactoring Project and, although things were looking up last time I was here, they've managed to adopt some bad habits in my absence. The latest build that's live with users isn't tagged in CVS; we have 66 other builds that are tagged and the ability to rebuild an arbitrary release has helped on numerous occasions, but this time they decided not to bother. But worse than that, they haven't been running the tests. Monday is Thanksgiving day in Canada, we found that out because they didn't run the tests...

Tests as tours Posted by Len at 17 Sep 2004 06:33 PM
I've discovered something quite amazing this week; something quite simple that shouldn't really have been much of a surprise, but it was. If you have a substantial set of unit tests then you can use them as the backdrop for documentation that tours the code base in a controlled and manageable way. Kinda like a sing-along, the reader can be directed through several key tests in a debugger whilst the document describes what's going on and reasoning behind some of design decisions.

Yup, that's where the value is Posted by Len at 14 Sep 2004 08:47 PM
Mats writes about how he finally got unit testing by realising that the value comes not when all your tests pass and you feel happy but when one of your tests fails and you feel sad...

Code coverage and testing Posted by Len at 4 Sep 2004 10:49 AM
Recently I mentioned that we were in the process of adding additional tests to our code base. We'd been using JITT to reduce the number of tests that we wrote and now it was time to fill in some of the gaps. This week I started to use some code coverage tools to see how well we were doing with our tests...

Repaying the technical debt Posted by Len at 26 Aug 2004 11:21 PM
The boss is away, we've almost done all the things he asked us to do before he went and, well, there's a bit of spare time so we're looking closely at the code. The last few weeks have been a bit of a push for the finish and now I'm looking at stuff and trying to work out how to repay the technical debt we accrued during the push. Sure, I could be surfing the web and kicking back but, well, it just seems appropriate to work out how much we now owe to the code and how we can pay that back before we're asked to push a little further and incur a little more debt... It doesn't hurt that I find this kind of work relaxing and not that much like work...

Practical Testing: 11 - Moving away from the simplest thing Posted by Len at 21 Aug 2004 01:59 PM
Previously, on Practical Testing: having decided to rework the code from scratch in TDD style we fixed the tick count bug for the second time - this time the solution was cleaner and simpler. At the end of that episode we were left with a failing test. The test was for multiple timers and it failed because our TDD route was taking a 'simplest thing that could possibly work' approach and that design only supported a single timer. Today we'll fix that problem by moving nearer to a real world solution.

Just In Time Testing Posted by Len at 21 Aug 2004 01:33 PM
Once we'd integrated the new data provider we were in a position to do some more testing. We configured the code that used the new component to request the same data from the new component and the old code and to save the data to files. Then we wrote some code to compare the files and highlight any changes. Once that was done we located the source of the differences, wrote tests that failed due to the problems and then started to fix the bugs. A while ago I called this process Just In Time Testing (JITT); it's like TDD-lite. You start the code in a TDD fashion and write that first test but as soon as you feel the baby steps and tests aren't giving you the best bang for your buck you switch out of TDD mode knowing that you can drop back into it at any point. Find a bug? Write a test. Fix the bug. Write no bugs. Write no tests. Just In Time Testing...

Singletons and testing Posted by Len at 20 Aug 2004 11:50 PM
When you need to jump through hoops to write tests you've done it wrong. Jonathan de Halleux writes about testing singletons and how he can subvert the standard C# singleton pattern to create a new singleton for each test he needs to run for the singleton. Omer then subverts the rules another way. Both are wrong.

Practical Testing: 10 - Fixing the tick count wrap bug, again Posted by Len at 24 Jul 2004 08:24 AM
Previously, on Practical Testing: having bolted on some tests to an existing piece of code we're now doing some "agressive refactoring" ;) and rewriting the code from scratch using the testing ideas we developed earlier. The whole point of this exercise was to fix a known bug, we did that in the existing code here, now we have a test that forces us to address the issue in the new code.

Practical Testing: 9 - More tests, more development, notice the order? Posted by Len at 21 Jul 2004 11:35 PM
Previously, on Practical Testing: we fought through the pain of writing tests for hard to test code and then we decided to see what it could have been like if we'd developed the code test first... Now we'll add some more tests and some more code, still keeping it all nice and simple...

Practical Testing: 8 - Once more, with tests first Posted by Len at 21 Jul 2004 09:58 PM
I've been writing some blog entries about a piece of code from my 'back catalogue' that didn't have tests and that had a known bug that was reasonably hard to test for. Right at the start I commented that the code was a tad over complicated due to the way it had been developed using HITIW (Hack it till it works). The complexity in the code itself made writing tests for it harder than it should have been and, well, I wouldn't write code like that these days (honest). So, here we are in part 8 and I'm about to throw the first version away and write a new version of the code and this time we'll do it test first and take a look at how the desire to be able to test the code shapes the design. I know you're probably thinking that this is just a bit contrived but I really did just sit down with an empty file and the tests that I had from last time and write the simplest thing that could work to pass the first test...

Practical Testing: 7 - Fixing the tick count wrap bug Posted by Len at 21 Jul 2004 08:45 PM
Previously on Practical Testing: After far too much work we finally got to the point where we had a test for the tick count wrap bug. Now that we have a failing test we can fix the bug.

Testing Reflections Posted by Len at 20 Jul 2004 11:11 PM
I found this site today from my server log - testingReflections.com I haven't explored it fully yet, but what little I have seen looks good...

Testing payback Posted by Len at 17 Jun 2004 11:08 PM
I'm building a new data provider for one of my clients. It breaks a huge chunk of their existing codebase out into a new component that hides behind a simple COM interface and abstracts away lots of nasty stuff so that they don't need to worry about it. The inflection point is small; a method or two on a single COM interface. This is good as it means we have a single, easy to test, integration point. Beyond the interface I can do what I like; all I need to worry about is that the stuff I throw back through the keyhole is the same stuff they'd get from their existing 'solution'. I started by writing some tests, so it's not really that hard...

Testing shouldn't be that hard Posted by Len at 26 May 2004 07:40 AM
Yesterday's Practical Testing post was a bit of a mammoth testing exercise. The threaded nature of the component under test makes testing it harder than you'd think; and this is just a single worker thread that we have to worry about. The thing is, I expect that the component would have been designed slightly differently if it had been developed test first; using TDD, or even with just in time testing, (JITT?)...

Practical Testing: 6 - Tests refactored Posted by Len at 25 May 2004 06:10 PM
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...

Practical Testing: 5 - Testing shouldn't be this hard Posted by Len at 25 May 2004 01:00 PM
I'm writing some blog entries that show how to write tests for non trivial pieces of code. This is part 5; the one where we find a bug we weren't expecting...

Practical Testing: 4 - Taking control of time Posted by Len at 19 May 2004 10:49 PM
I'm writing some blog entries that show how to write tests for non trivial pieces of code. This is part 4.

Practical Testing: 3 - Test 2, Enter The Mocks Posted by Len at 18 May 2004 11:30 PM
I'm writing some blog entries that show how to write tests for non trivial pieces of code. This is part 3.

Practical Testing: 2 - The first test Posted by Len at 17 May 2004 08:42 PM
I'm writing some blog entries that show how to write tests for non trivial pieces of code. This is part 2.

Practical Testing: 1 - Introduction Posted by Len at 17 May 2004 07:51 PM
I'm writing some blog entries that show how to write tests for non trivial pieces of code. This is part 1.

Practical Testing Posted by Len at 17 May 2004 06:40 PM
One of the common complaints about TDD and unit testing that I see is that the examples used aren't real. People often say that the examples used are toys and that writing such tests adds little or no value. To be honest, I often find myself agreeing with them. One of the problems of adding unit tests to an existing code-base or driving a new project with TDD is deciding exactly where to spend your testing efforts. This is more of an issue when adding tests to existing code as I personally find that the safety of TDD on new code becomes slightly addictive... Anyway, in an attempt to show how adding unit tests to existing code can be worthwhile I've decided to write a series of blog entries on Practical Testing of real world code...

Wafer thin testing? Posted by Len at 26 Apr 2004 10:51 PM
I've spent the past month or so helping a corporate client improve code quality in a sprawling application. It's non-trivial, the code-base is huge, the quality is, at best, questionable and the coupling is excessive and made worse by the fact that much of the system is coupled together using a single huge blob of relatively unstructured XML. Fun, fun, fun...

Testing synchronous communications Posted by Len at 26 Mar 2004 03:53 PM
Today I'm doing some work for a client that involves writing some blocking sockets code to talk to one of our servers. Blocking mode fits well with the architecture of the client application they use; we're moving the app from blocking reads on a serial port to blocking reads on a socket and jiggling the protocol it uses a bit. Testing blocking calls is actually a bit harder than testing non blocking calls because hand cranking the mock objects so that your object under test works correctly is harder to do when your test harness is blocked in a call to read() and wont come back to you until the call times out (and the operation that you're trying to test fails) or the read completes...

Async Pop Posted by Len at 25 Mar 2004 10:24 PM
A while back I finally started on the async version of the POP3 client. It ended up as a state machine and seemed to work well. The next step was to write an async version of the mail collector that I used to pull all mail from a mailbox on a server and optionally delete it.

Jimmy on TDD Posted by Len at 25 Mar 2004 08:19 AM
I agree 100% with this piece from Jimmy Nilsson's blog.

Meanwhile, back with the tests Posted by Len at 13 Mar 2004 02:05 PM
I've seen a lot of blog postings recently that pour scorn on the ideas behind TDD. Ah well, if you don't like it, don't do it. I'm more than happy if our competitors decide that TDD isn't for them. In fact, testing is bad, don't do it, move along now, don't read any of the testing articles here...

Craig on TDD Posted by Len at 4 Mar 2004 09:06 PM
Craig Andera talks about TDD. I couldn't have said it better myself....

POPing back Posted by Len at 2 Mar 2004 09:44 PM
Way back in mid November, before we dumped our building's managing agent for being worse than useless and possibly stealing from us, I was working on some POP3 code. I had some down time today so I decided to drop back into it and see if I could move things along a little. In summary, having lots of tests helped...

Uncontrolled coupling - Singletons, just say NO! Posted by Len at 23 Feb 2004 01:12 PM
We're developing some code for a client. There's a standalone server, which we've completed, and a small stub of code that allows the client's existing system to talk to our new server in place of the old thing they used to talk to... This morning I stubbed out the new stub and put together a test harness project. Unfortunately, due to the way the client's code is coupled it could prove difficult to test the new stub...

I seem to have lied earlier... Posted by Len at 20 Feb 2004 08:24 PM
Earlier I said "I'll probably keep the code for now, but it's not the code I'd have written first if I was working from a test. I wouldn't need it yet... I may never need it in production..." I lied. It's in CVS if I need it, so why keep it cluttering up the code when I don't need it...

Test Driven OBEX Posted by Len at 20 Feb 2004 04:52 PM
Way back in June I was playing around with OBEX. I've had a quiet day today and went back to the code to progress it a little more (a client is making interested noises so I need to get back up to speed again). The code I wrote in June was before I'd become test infected...

Can performance tests treat the object under test as a black box? Posted by Len at 12 Feb 2004 12:05 AM
Barry suggests that to do meaningful performance tests you need to know a bit out the way the thing that's under test operates.

Where do the mocks live? Posted by Len at 2 Feb 2004 11:59 PM
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...

So, what do these tests look like then? Posted by Len at 28 Jan 2004 11:45 AM
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?

Hacking our way to the first test Posted by Len at 27 Jan 2004 06:24 PM
So I have some time on my hands and I've decided that the socket server 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...

Edit my points Posted by Len at 2 Dec 2003 09:45 PM
The refactoring project rumbles on but my time with it is drawing to a close. This week the currency traders decided that they wanted to be able to manually override the live data in some circumstances. They wanted to be able to edit a live data point, set its value to a fixed amount and have all dependant displays take this new value into account. Like most things in computing an extra level of indirection saved the day...

Promote a mock Posted by Len at 23 Nov 2003 01:52 PM
I knew it would happen eventually... As mentioned earlier all of the email filtering code has been developed without any sign of a main(). Now that the time has come to create the actual filter program I found that I didn't actually have a real version of one of the objects that I required, I only had a mock version for testing. The thing is, the mock version is pretty much all I need for the real version, so it looks like it's time to promote it...

Rolling... Posted by Len at 20 Nov 2003 06:45 PM
The first two filters were pretty easy. I was on a roll and the other filters were implemented just as quickly...

Just enough RFC822 Posted by Len at 20 Nov 2003 04:48 PM
Second on my list of email filters was a filter that splits a 'domain mailbox' into several different mailboxes depending on the username that the email is addressed to. This is basically just an intelligent version of the mailbox writing filter. The problem was, it needed to understand RFC822 addressing...

The one where I dont use XML Posted by Len at 20 Nov 2003 02:33 PM
So I have an email filter that can write messages to another mailbox. I need to supply it, and all other filters that I might write, with some configuration data. I could use XML but I dont...

Filtering mail Posted by Len at 20 Nov 2003 01:08 PM
Now that I can retrieve POP3 mail and serve it up again via a POP3 server I want to do stuff to it in between retrieving it and serving it. The idea was to have a series of filters that get passed each message, Do Stuff (tm) and either allow the message to be passed on to the next filter or end the filtering process. Most of that works now, here's how I got there.

Dealing with the simplest things Posted by Len at 6 Nov 2003 08:40 PM
The POP3 client is now complete. It can download messages from POP3 servers and store them in a message store. I've implemented a file system based message store that is compatible with the POP3 server code's file system message store. We can download messages from server's and make them available via our server. As expected the test first approach had driven the design in a simple and decoupled direction; eventually some of the simple decisions were inappropriate so I added some tests and refactored...

POP3 Client almost complete Posted by Len at 25 Oct 2003 11:52 AM
The test driven development of the POP3 client code is almost complete. The development proceeded in a similar manner to the server code and I'm left with the same thing to write; the message store...

Dirty Little Secret: Test code is fun to write Posted by Len at 21 Oct 2003 08:10 PM
I've been busy :( but it's paid busy so I suppose I can't complain... This evening I got some time to myself to finally sit down and see how hard it would be to use all of my previous test code plus the real production POP3 server and command parser to act as a test framework for my POP3 client. It took just over an hour to plug it all together and then it just kinda worked...

James Antill doesn't like TDD Posted by Len at 20 Oct 2003 08:25 AM
And this is why I hate TDD, testing is a great thing. But testing too early is bad, and you are obviuosly doing that. First you need to know what your code has to do in full. For instance even if you wanted to have both sync. and async. APIs (I personally abhore sync. APIs due to non-scalability) the obvious implementation is to have something like... James Antill - in a comment on my Tangled Testing entry. James, I disagree... James Antill - in a comment on my Tangled Testing entry.

Tangled testing? Posted by Len at 17 Oct 2003 08:28 AM
Last night I started on my POP3 client code. I didn't know where to start; I wasn't really in the mood, so I wrote a test... That got the ball rolling. As usual the test first thing left me with a nicely decoupled class to write. Now I'm in a bit of a quandary about how to mock up the server that I need to test the client against...

Tests and TDD in anger Posted by Len at 15 Oct 2003 11:45 AM
This week we started to make some changes to the FX code. The existing code made some strange assumptions about some of the edge cases and the resulting display was occasionally inconsistent. We fixed that, and the tests saved us from a couple of embarrassing mistakes. Meanwhile, in my free time, the test driven POP3 server development continues. I now have a working server that can run off of a message store that lives on the file system and can do all the things that a POP3 server is supposed to do. So, did the test first approach help?

Why objects should keep it on the inside Posted by Len at 7 Oct 2003 09:27 PM

So, I'm integrating this POP3 code with my server and the first thing I do is create null message store. I haven't implemented the message store yet, so in order for me to integrate I need a message store that just says yes to everyone being a user and provides mailboxes that are always empty... The test driven development has made this reasonably easy, I have a message store interface so I just need to stub out the methods appropriately. It's then that I find that the interface is bad...



Does TDD lead to earlier integration? Posted by Len at 4 Oct 2003 12:16 PM
I'm developing a POP3 server. I've been developing the protocol handler test first and it's nearly done. I haven't started on the mailstore itself yet but I could easilly integrate the POP3 code into the server code and have a functional POP3 server...

I blame the testing Posted by Len at 8 Sep 2003 10:46 PM
It's amazing what a day or two away can do. I came back to the tests with a fresh mind this morning and dealt with the issues that had caused me problems at the tail end of last week before I got my morning coffee.

Insufficient coverage Posted by Len at 4 Sep 2003 08:07 PM
Today the FX engine went into UAT. Well, the nearest thing we have to UAT; a user looked at it... 3 bugs, differences between the new code and the current production version. All slipped through our test coverage. :(

Decoupling the FX GUI Posted by Len at 21 Aug 2003 06:59 AM
The rates engine was now easy to test but the interaction between the engine and the user wasn't. This was unfortunate as the interaction is reasonably complex. We hadn't built and tests for any of the GUI code yet, last week we fixed that...

FX Testing Posted by Len at 17 Aug 2003 09:55 PM
By Friday our FX test harness was pretty much complete. We had coverage for all the nasty special cases that had caused us problems in the last few weeks. They were the hard things to write tests for so we...

Writing tests for new code vs writing tests for legacy code Posted by Len at 13 Aug 2003 07:13 PM
I was working for my poker game client yesterday. This project now seems to be firmly test first. What was interesting with yesterday's work was how the tests drove the design and how when I finally came to integrate the tested code into the main body of code the required design changes weren't an issue as I had a whole load of tests to support the changes.

You'll tick when I say so and not before! Posted by Len at 13 Aug 2003 06:43 PM
Today we wrote some complicated FX business logic tests. Things like making sure that the FX library can calculate a EURUSDCAD 1M rate - it can; or a USDCAD ON rate - it can't...

The first FX test Posted by Len at 11 Aug 2003 07:28 AM
On Friday we got to the point where the FX buiness logic code was suitably decoupled from the display logic that we could write our first test for the business logic. In the words of Homer Simpson, "Woo hoo!".

The onset of infection Posted by Len at 23 Jul 2003 12:12 PM
I've spent the morning doing test driven development, properly; writing tests first and everything. It works, it's faster and it's addictive....

Untestable 2 Posted by Len at 9 Jul 2003 07:11 AM
A couple of days ago I posted some untestable code. I've had a couple of emails saying that people couldn't see why the code was untestable. Here's why, and here's how to fix it.

Three bugs went into a program Posted by Len at 7 Jul 2003 07:01 AM
Three bugs went into a program; a memory leak, a misunderstood interface and a deadlock...

Untestable Posted by Len at 5 Jul 2003 12:05 AM

It's easy to write untestable code. It's natural. Most code that we write will be hard to test unless we explicitly think about testing when we write it...

This code is really simple, yet it's untestable. Why?


That test driven development thing might just work Posted by Len at 26 Jun 2003 09:31 PM
And then I began to develop test first...

Stage complete. Time bonus... Posted by Len at 4 Jun 2003 06:24 PM
This morning I wasted some time tracking down bugs in the multi-threaded online game engine that I'm writing for a client. Now I have tests. Tests are good....

We came. We saw. We did a little testing. Posted by Len at 31 May 2003 12:06 AM
Another week another release. Well, almost. The plan was to release today. The plan ignored the fact that most of the team are at a wedding this weekend and nobody was around today and nobody's around on Monday......

Test-Driven Development (By Example) - Kent Beck Posted by Len at 27 May 2003 07:57 AM
Kent Beck demonstrates the testing side of XP by separating it out into its own simple methodology. Test-Driven Development is exactly what it says it is. The entire design and development effort is driven by the tests that you write...

Our first test Posted by Len at 26 May 2003 08:44 PM
The refactoring project reached an exciting new stage on Friday. We were finally able to refactor some code to the point where several classes could be extracted from the application project and built in a library that the application then...