Free Development Tools and the Command Line

My last company spent a lot of money on development tools. Every developer has an MSDN subscription with a Team System license. (They wouldn't buy me Resharper or another GB of RAM, but that's another story.) Since I've moved companies and now I have no budget, I've had to use cheaper tools.

Subversion and Trac have both done a great job. I spent a while looking for a way to integrate Subversion into Visual Studio and couldn't find a good way. It turns out that TortoiseSVN is just as good as VS integration. TortoiseSVN is integrated into Explorer and it makes your folder into the working copy of the repository. Right click and click on "TortoiseSVN Commit..." and all of your files are updated. Trac has really helped me get organized which is really necessary when there aren't any other developers.

I also finding myself using the command line more often. Subversion without TortoiseSVN is based on the command line. Trac projects are initialized and administered by the command line (although administration can be done via the web interface in the next version or with a plugin). I've almost become afraid of the command line as I got better with Visual Studio and had tools with GUIs, but it's pretty useful. I wish PowerShell didn't have such a steep learning curve, I may be better off writing simple one-off console-based applications.

What actually takes the most time?

Next time I write a web page, I'm going to try to keep track of how much time I spend on each task. It seems like I spend the most time doing repetitive things. These are the types that are most easily done by the computer. Two things quickly come to mind. The first is creating a row in a table that has a label and a form field and the second is collecting the form input and putting it into a data structure.

The first could be solved by a user control. I haven't created one yet because it's not trivial. It needs to be able to handle every option on every form control and it needs to be flexible enough that my designer won't nitpick that it doesn't look exactly like the screenshot. This makes me think about whether it's worth the time investment because creating the row is really quick. I've forgotten about the secondary gain: having a form-independent way to create a form.

The Pragmatic Programmer makes the point that it's better to work closer to the domain. This means using their jargon and letting the domain experts define the requirements. It would be very quick and productive if they could type up something that the web site will parse directly into a form, even it's just a prototype.

The second thing isn't just to save time. A class that takes the form response and fills in properties on a data class would be very useful. I haven't done this so far because of the myriad validation possibilities and it requires reflection (which makes me pause but it shouldn't). There are many possible ways to handle validation, including the Validation Application Block or to handle it completely separately.

Test Plan as Requirements

My first project at my new job was a pretty simple web site. I didn't use the data controls (like DetailsView), although they would have been appropriate. I didn't write unit tests either, mostly because the application fills out forms that directly reflect auto-generated SubSonic classes. There was one place where I should have written unit tests, but only one. I did write a test plan.

A test plan, in theory, should cover every behavior that the application should exhibit. If the application is supposed to flash the background color every 10 seconds, there should be an item on the test plan that says "The background color flashes every 10 seconds". If there's no requirement for that to happen, it shouldn't be in the test plan. So the test plan should echo the requirements document, if you have one. Which you probably don't, so writing a test plan gives you requirements.

The real reason to write a test plan is to separate you the developer from you the tester. Testing something that you developed is tricky, because if you just dive in and test, you're not going to test very well. You're going to test the things that come to your mind, which is probably the things you worked on the most, which probably doesn't have bugs since you worked on them the most. Writing the test plan properly, by looking at the UI and writing down everything it should do, separates these two personas.