…and were Live!
Ok, so it took me all day but I finally did it. As promised:

I know what your thinking. Only 69 tests, thats really not too many. I know, I know, but believe it or not it took me a long time to get those tests working 100%. I spent the better part of today refactoring and reworking the tests to try and get them all to pass. They are pretty basic but amazingly enough they enabled me to find some pretty big bugs which I had subsequently fixed.
I’ve been learning alot about C# and the whole visual studio team system suite lately. Stuff like proper assembly usage and common coding practices that I never really needed to delve into when using c# before. Though I must admit that some things that would take experienced Microsoft programmer seconds to do sometimes took minutes or hours since I had to look through various documentation to find the right line to add to fix everything.
The Unit Test Hour:
Unit testing is fun! Trying to break your own software is just cool. After spending countless hours trying to perfect a specific function or class its nice to just let loose and try to break it, ON PURPOSE! It’s also very satisfying to see all the little green (and red) icons light up after hours of black and blue coding; pun intended. I have no problem breaking my own code, it also usually gives me a good idea of what to focus on next.
After hours of trying various approaches to Unit Testing Web Code and coding some of the more basic unit tests for other classes I eventually realized that I could use the JAXB approach. Here’s what I did. I used the template classes that are used to de-serialize the incoming SOAP XML from TFS and instead created a method which, when presented with the appropriately filled class serialized the data. I then passed this “sample data” to the methods which handle the incoming TFS SOAP XML and added code to each “notify” method to return true or false based on whether the sensor could send data or not. Very JAXBish. The only problem with this method though was that the Unit Tests were located in another project and I couldn’t find a way to access the classes I needed without copying them over to the Unit Test project. VERY BAD PRACTICE. But for now it seems to work. If anyone can suggest a better way of referencing classes from another project under the same solution please, please, please email me. I think it has something to do with assemblies.
Another thing to note. You should always make sure to develop your unit tests as self sufficient tests. Assume no order to which the tests are run. I came across this problem when I was writing my tests. Early on I found that some of the tests which queried the database would fail when run the first time. On a second run however, some would fail and some would pass. Very strange. On investigation I found that this occurred because the first time they ran they modified the entries (or the database itself!) which then created a different test context the second time around. I think I’ve gotten it a bit more balanced now. I create an entirely new database for testing. After I am done testing I simply delete the newly created database. It’s slow and cumbersome but it works really well and I don’t think people will be testing on a production server so I think its a good compromise for developers.
In the know: Namespaces
Useful little things. At first I didn’t see a need for them but they really help to separate the structure of classes and code. I am currently trying to add namespaces to my classes so that I can see a logical grouping of code that belongs together in the object browser.
Documentation with Matt in the Morning:
I’m finding alot of problems that I am having is with documentation. Surprise, surprise. Though I am not quite having the problems you would think. Sure there is a lack of good documentation on lots of things but I think that is to be expected. The real problem I am having has to do with legacy documentation. I’ve been reading alot of documentation which ends up being the wrong documentation for the current version of the software I am using. Whether its the hackystat version 7.0 docs or the Visual Studio 2005/2008 documentation, people tend to eithier incorrectly label or provide very few labels as to which version of software the documentation pertains to. Then there is the problem of old documentation when the current archive is moved to a new location, updated, and the developers fail to remove the old documentation. I think a critically overlooked problem with documentation for developers is that they must keep all documentation for each version clearly labeled, sorted, separated and in one place. This is probably one of the reasons Wikipedia does so well. Its all organized in one place and its extremely difficult to find old versions of wiki pages. Sometimes its actually a good idea to either update the documents or simply delete them entirely to force people to find the new ones. Archiving like pack-rats does not a good developer make.
…and he rode into the courtyard, at sunset, with only seconds to spare: GUI
Well its not that good but I spent some time this week redeveloping the structure of the GUI.

Its a bit bland and has many css errors but it looks better than before. I will probably change it a few more times before the end of the project. Suggestions are always welcome.
Whats next
Now I plan to do some more advanced things. Besides better unit tests I am going to delve into the Team Fortress, I mean Foundation, Server and see what data I can pull in addition to what is given when an event occurs. I should be able to pull at least a little more data. I was also thinking of comparing changesets from source control when a new changeset is checked in to give a better idea of what exactly developers are checking in.
B.T.W. This blog GUI really makes my post look longer than it really is.
B.T.W.x2 Anyone notice how most programs are adding in instant spelling support with little wavy red lines right under our noes. I just used TortiseSVN today and when I spelt something wrong it suggested the correct spelling.