I learned that the anonymous types in C# 3.0 has got a good feature that, if you have two anonymous declarations with the same signature, then you create only one anonymous type and have two instances of the type. So, a code fragment like the following is perfectly valid and passes all compiler warnings/errors- var anon = new { FirstName = "first", Age = 21 }; var anon2 = new { FirstName = "

I was wondering to find out the easiest methods to write unit tests for. I came up with a few results as the following ones... a. A method that takes no parameter, perform calculations on only local data and always returns a constant value is the easiest to test. But the question is, is this at all important to have such methods? b. A method that takes some parameters, and limits its operations only on the supplied parameters and local variables and returns some value or throws exception is also very easy to write a test for.

Dissection of void Methods without parameters Methods with void return types incur complexities in writing unit tests. So, we need to characterize the void methods to make sure we have guards against the odds for testability. A typical void method without any parameter looks like the following public void DoSomething() { //1.modifies some member variables this.someMemberVariable = 10; //2.Calls methods of the same class or other classes someClass.SomeOtherMethod(someArg); //3.Sometimes throws exception

Dissection of void Methods with parameters Methods with void return types incur complexities in writing unit tests. So, we need to characterize the void methods to make sure we have guards against the odds for testability. For example, the following is a void method with parameters public void DoSomething(SomeType obj, SomeOtherType objOther) { //1.modifies some member variables this.someMemberVariable = 10; //2.Calls methods of the same class or other classes

An application is supposed to have a graph of objects as a result of the following- 1. Objects are designed to be interacting with each other following two rules of thumb "Highest Cohesion" and "Lowest coupling". So, a class instead of taking all the responsibilities only takes care of some high cohesive ones and depends on other partner classes for the rest of the services. This dependency creates a graph like structure with objects as the nodes and dependencies as the edges.

Up to now, I have figured out that teams trying to behave agile sometimes fall into the cave of pretending to be agile (e.g. stand up meetings and less than just enough planning and short iterations so on!). Often, when this pretending takes places for days, it creates a illusion on the minds of the people that they might be doing the "right thing". And all on a sudden, someone discovers things are breaking and there is no way out of this disaster!

I have been in practice with the famous agile software development process called "Scrum" for more than a year. I have had the opportunity to see a SCRUM team developing from scratch in a completely start-up environment. I will point to the two aspects as, 1. Management aspects. 2. Technical aspects. 1. Management aspects I encapsulate the things like working on a story by story basis, standing up for daily status update meeting, producing deliveries in short iterations and without much of prior planning into this group.