Test Driven Development

I'm sure most of you have already heard about Test Driven Development (TDD) and if you haven't you probably should.

My experiences with TDD have been limited and experimental at best. The point of TDD is to develop your test cases before you do the actual code design and implementation. Sounds funcky right? How can you write the code for test, if you don't have the classes and objects to compile it?

Well, this is how you do it:

• you come up with the object model for the feature you are going to test,
  
• write up the test case based on the requirements; it will fail initially so don't panic. It's all part of the Grand P-l-a-n,
  
• write the simplest means to pass the test, like return 1+1; //passes test that asserts for 2
• write the simplest code logic to solve the problem and make the test pass.
  

This will give you simple design and code to match your requirements (pass the test).

TDD is one of the main principles for Agile's Extreme Programming (XP). My encounters with it, as I said, have been limited and experimental at best. The first time I came across actual use of it was at Microsoft's Imagine Cup competition. The code that was to be designed and submitted already had test cases written against it to make sure that what we code matches what they want. That's how you get the points.

The next actual application of it was with a test project that I created at my work recently. I was to design and code this Engine that takes in certain inputs and is supposed to return certain output. A normal regular function. I decided to take the data-driven test approach, kinda like Microsoft's VS Test framework, using Unit Test and Xml.

I put all my expected output and all different permutations of the input criteria as test cases in the Xml file (each Test case was an element in the xml with the expected and input criteria as attributes to the element).

My unit test function was then pretty simple, load the xml to a typed data set, read each row of test case from the data set and apply the input criteria to the engine function, and assert them against the expected output from the Xml.

Of course, I had to write a couple of other test cases to check for corner cases like null inputs, stress conditions etc. But my data was abstracted from my test logic and now I don't have to touch my code in order to add new test cases. Pretty slick huh?

Added bonus: I can use code to generate the xml file as well :)

The pain of writing research papers...

It's the job of graduate schools to make you read, review and eventually write research papers. I am currently doing that too. Writing a research paper that is. Its called a thesis.

There's no easy way that helps one write a research paper, or at least I haven't found one. Please do correct me if you have found one; I'd love to know about it and make my life easier.

You read so much literature, try to put them into your work and voila, something you read just yesterday and wanted to articulately add to your brilliantly written work goes poof from your mind when you momentarily shift your attention to something else. I don't know about you, but that happens way too much for my comfort.

There was one class I took in the first year of my undergraduate that had me write a research paper and gave me guidelines on how to do good research. I'm still hitting myself for not remembering much of them or retaining the guidelines in print. But one thing I do remember is the use of 3x5 note cards in the research.

So here's my guidelines on how to write research paper (of course incorporating what I do remember of the use of note cards)

1. Organize your paper before you start writing it.
2. Formulate questions that you are trying to address in your research (curtsy of my adviser)
3. Find and read relevant research material.
4. Play special attention to this point - while reading, if you find something that strikes you or you think might help you answer one of those questions, or even if it just comes at you like "Oh hey, I can write it like such and such", just pick a note card, write what you thought on one side, and then write which subject or class in your organization it belongs to on the other side. Make sure you note where the information came from and what page it came from (specially if you are writing quotations). Recently, I'm starting to think that its a good idea to carry a few note cards with you where ever you go, because if you are like me then you don't stop thinking about the project even if you have closed the books for a while.
   
5. Later you can go through and sort the cards by the classes/subjects in your organization.
   
6. When you are writing about the topic, you can use the cards to formulate your argument and provide very good references to support it using the cards.

Well, right now I'm at the part where I'm writing the cards while I'm reading the references. Cards and notes. But I think I have enough information for some sections that can help me quickly write them when I do get to them. A similar method helped me when I was writing that research paper till 11 p.m. in a library as an undergrad before they threw me out while they closed. Let's see how it fares against graduate school.