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.
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…
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…
The first two filters were pretty easy. I was on a roll and the other filters were implemented just as quickly…
Now that I could parse 822 addresses blacklists and whitelists were easy to implement. Some refactoring could be done to remove the common ’list’ handling as effectively a blacklist is simply a !whitelist…
Once I had a whitelist filter I decided that it might be useful to have a way of ORing two filters together, so we could filter a filter that does something like “if the message isnt in the whitelist then strip all attachments”… An Or filter was easy to implement and test once I created a mock filter that allowed me to programmatically control what I returned from the call to FilterMessage().
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…
I have several POP3 mailboxes that work at a domain level. For example I can recieve pretty.much.anything@lenholgate.com. The guys that manage the domain supply me with a single POP3 mailbox and I’d like to split it locally using a mail filter.
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…
Filters are given an instance of an IFilterDataManager when they’re created; the idea being that they can obtain any configuration data that they need from it. More advanced filters might also want to write data back once they’re done, but that’s a story for another day…
Now that I can retrieve and serve it up again via a POP3 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 ™ 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.
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…
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…
I was quite pleased that the entire client development could be done without needing to connect to a real POP3 server at all. In fact, up until last night, I didn’t have any code that the client could use to talk over sockets.
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…
