VS2010 Beta 2 is out!

Check out the new VS2010 Beta 2 Announced yesterday!

http://blogs.msdn.com/jasonz/archive/2009/10/19/announcing-vs2010-net-framework-beta-2.aspx

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.

How would you test ....?

A standard interview question that Microsoft asks is "How would you test X?" where 'X' is a common everyday item like a pen, toaster, ATM etc.

Now you can ask, how does this relate to Software Testing at all? To be honest with you, I thought the same when I was once asked "How would you test a vending machine?" At that time my answer went along the lines "... put coins in it and see if I get the right item...". I learned later that Microsoft asks these types of questions not to get a whole bunch or 'right' and 'wrong' test cases but to see your thought process - how would you go about testing something out of the box. As was told to me after that disastrous interview, people with a testing mindset automatically start categorizing their test cases as Functional Testing, Stress Testing, Load Testing etc.

Here's a blog entry I found written by Mike Kelly while doing some research and preparing for another interview with Microsoft. It lists 144 test cases on how to test a stapler. Pretty impressive huh? It was inspirational actually and I can honestly tell you that going through it and reading through other manuals seriously helped me develop a testing mindset close to what that interviewer told me. I am still a Software Developer at heart though :p

Design Patterns Trivia!

How confident are you in your design patterns?

Here's a site to test out your design patterns recognition - GoF design patterns quiz. This quiz is good to familiarize yourself with recognizing design patterns when you see them. Its not very good for judging when to use the pattern in your code or what problems it solves, but it does give you hints. You need to do match a given pattern with its name.

Here's an example - can you recognize what pattern this is?

Here are some hints:

• Recursive composition
• 1-to-1 'has a' up the 'is a' hierarchy
• Intent: Add additional responsibilities to an object dynamically

Any guesses?

Answer is Decorator Pattern.

Joel on Software

Ever heard of Joel on Software? Coming out of school you might not have heard of it and even for some years afterwards. I didn't know about it either until just recently. My boss made me take this software test The Joel Test: 12 Steps to Better Code.

Joel on Software is a weblog on software engineering. In short, it is the Office Space of software commentary coming from one person's experience - Joel Spolsky. When I say Office Space, I mean the movie and its witty comments about desk life and computer programmers in general. Mr. Spolsky uses witty commentary to keep his readers enthralled and in the process manages to make them understand some really neat tips for survival in the software world.

His logs have been converted into books but they are actually freely available on his website. I like his style of writing and his logs are an interesting read on any day. Its like reading Shakespearean comedy designed for software engineers, just much easier to understand. If you have ever read Much Ado About Nothing then you know what I mean. Its a good site to learn more about the non-academic aspect of software, aka the Real World.

Logic Puzzle

"You have 9 metal balls. 8 of them have the same weight, 1 is heavier than others. How can you find the 1 which weighs different from others in 2 steps?"

This was a question a friend of mine was asked in his interview. Its an interesting logical question and not something people might expect to be asked in an interview. Its easy to solve once you know how. My friend asked me this question, and I started of saying "divide the balls into 4,4 and, 1 and weigh them." Its the right way to solve the problem but turns out that my solution would take 3 steps to find the ball.

The right answer is dividing the balls into 3, 3 and 3. And weighing 1 group against another. If 1 group is heavier - that one has the ball. If the 2 groups weigh the same, the heavier ball is in the last group. Now take the group with the heavier ball, and apply the same idea with 1 ball against another. You have your ball now... and the answer to the question.