Recently, for Software Systems, I had a group project to build an SMTP and POP3 server and client. Milestone 1 was a simple single-machine implementation, Milestone 2 will be a clustered implementation. I was primarily responsible for the SMTP server.
Moreso that most problems I have to solve, this was a really good chance to practice doing software development the "right" way. We had a clear protocol spec, separable parsing/formatting and protocol logic, and a need for configuration in terms of the backing store.
One goal was that almost any line in the server should be runnable under unit tests. We accomplished this by programming almost entirely to simple interface, which let us make dumb mock implementations for test. This was especially valuable in testing the protocol logic, which with less care would have been connected to almost the entire rest of the system. Using a streamPair construct to replace sockets and a Session class to control a single user's connected session, we were even able to test full client-server interactions under unit tests with the overhead of only a single thread creation.
Now that we move on to the clustered implementation, we'll encounter more testing problems in that our tests need to ensure correctness and consistency in a distributed system. We'll be moving to an automated test system that will run long-running multi-client, multi-server tests on every check-in, as opposed to our current system which runs units on every build.
No comments:
Post a Comment