Chapter 9: Unit Testing

Chapter 9: Unit Testing

The concept of unit tests is not a hard one to grasp. But never before have I had such a code base to maintain that this has been an issue so this is my first foray in to this concept. The idea isn't to complicated. you create a roster of tests that the system has to run through in order to pass. you test each unit of the code so to speak. this way you always know it is behaving the way you think it should be. aside from providing a method of making sure everything is proper, it also gives you a better understanding of your own code. inorder to perform a unit test properly you need to know what to expect, so you have to go through as you are making the unit test and tell it what is expect so that it knows where it went wrong, approximately.

I'm going to start by working with the network layer. Start making unit tests of it. basically each function should have it's own set of tests. a set of tests because you need to test various kinds of input. and because of the nature of it, I'll also have to make a test like client. or declare 2 instances of it. but inorder to test the network I just remembered I have to have a functional file system. hmmm, actually no. Even though I have the file server as one of the arguments passed, that is only for the DNS server. Which starts to make this system make a little more sense. The file server sits on the bottom, it pulls is info from mail boxes and gives data to the DNS. So it really should be the first class to be unit tested. Then I'll make unit tests specific to the DNS class, some with the file system, some with out. With that working I should then test the connection class, make a battery of tests for it so I know those are always working. and only then with the other 4 classes (counting the DAL which I'll generate later so I won't need unit tests) will the network then be unit testable.

So The file server. what can go wrong with you. well the commands in the class:
getMailBox
Reactor
checkIn
remoteGet
remotePut
noFile
setBlock
clearBlock
getFile
newFile
newComputer
getComputer
newWU
newWUs
getWU
getIdleWU
newProcess
assignWU
distribute

Ok. so lets tear apart and lump together. There are 2 main ideas here. the first deals with the database back end, the second deals with the network mail boxes. Commands that deal with the database backend are newFile, new/getComp, new/getWU(s), newProcess, distribute, and assignWU. Commands that deal with the mail boxes are getMailBox, Reactor, CheckIn, remoteGet, remotePut, noFile, setBlock, and clearBlock. now getFile is a fun beast that ties it all together. now that I've divided lets conquer.

First up would but just to get the database to instantiate. if this fails then the rest isn't worth bothering with. Then add a file and pull the file back out. did that work? fantastic. add a computer, pull it back out. add a process, and work units, pull them back out. and see if a WU can be assigned. Because WUs depend on processes, I will have to put a process in first.

Just spent quite some time tracking down a silly little error. It is good to remember that the execute function for SQLite3 is looking for an argument and a tuple of paramaters. now, this is not a tuple: (par) but this is: (par,) the important important differences is that little comma because (par) evaluates out to par where as (par,) evaluates out to a tuple (par).

IT only took forever but I've finished unit tests for the file system's back end... so I'm half way through one system after 10 hours of work. goodness. I don't know how much I like test driven development anymore... anyway. on to the network end. I think this one will be significantly easier. it is also subdividable into 2 major categories. inbox and out box. of course a lot of things have to do with going form inbox to out box. but it shouldn't be quite as difficult I think.

The network end of the file server took only about 3.5 hours to test. probably because that system was programed in one inspired sitting. It was a little more complex as goes programing techniques required to make it work. but there was far few syntax and type errors that i had just tears of pain dealing with in the DAL. all the more reason for my belief that I will be generating that in the future. But I'm really getting the feeling for why maybe having explicitly typed paramaters would be a good thing. As well as passing information only in the form of explicitly declared classes rather than these slightly harder to wrap your head around arbitrary tuples. While I love the tuples so very very much, they can stretch your mind and are easy to forget and acidentally structure one differently. Thinking about them as common structs like in C helps.

Now I press on to debugging the network interface. which while it is slighlty more complicated that the file system. the testing of it should be relatively strait forward as I don't have to deal with data quite as much. things get passed through the network layer, they aren't mutated there. It is kind of easier in terms of the number of methods it has is significantly smaller, and there's less patch wrok. the system is divided into 4 seperate classes though, each will require thier own batteries of tests. The most annoying of which will be the DNS class, listener and Connection will take a total of 5 minutes each, and network I will probably have to think a little, but it isn't going to be a nightmare. so, lets see if I can finish these unit tests tonight eh?

The obvious place to start is the connection class. with the exception of the DNS server, the other 2 classes build off of it. so it should be the one to be made sure works first. of its three methods, newConnection, send, and recieve, 2 are essentially pass through methods. so this shouldn't take much. and even if there is something wrong, it isn't going to take a lot to repair.

I take that back. Listener needs to be tested first. because the connection class needs something to connect to. xD Also i've realized I may need 2 scripts running simultaniously inorder to accomplish this as there needs to be interactions which are what you'd expect to be needed. But I want to press on now. I've got confidence in this particular peice and its use will become clear as i press into the theory of the next 2 servers.