Adarsh's blog : Software Testing

"Test driven development" - some practical experiences in API development

adarshk — Tue, 06 Mar 2007 05:46:00 GMT

Since last few years I was reading a lot of discussion about "extreme programing" and "test driven development". I decided to explore and apply some of those principles in my own development and within my team. Here are some of the interesting things I would like to share. These experiences are based on a project for developing a public SDK.

Approach:

First thing I really did not try the hardcore methodology of test driven development. I took a little relaxed approach with relaxed restrictions.

My approach contains following category of pro-active and reactive actions.

a) Pro-active action was applied on all new functionality, here I did applied the rule that at minimum main line happy scenario code path must be included as an automated unit test and most common failure code path should be covered,

b) Second action is reactive approach, here when our test team reported any issue. Fix must include unit test and should also try to cover other related scenario.

In some sense this looks very relaxed compare to hardcore "test driven development" approach, but I found it is easy for adoption within the team and still contains lots of benefit in terms of time investments and returns.

Results from this approach:

Overall I was very encouraged with this approaqch and here are some of the fruits I found in applying this approach

a) Overall quality of regular build is improved with almost no regression in mainline scenarios.

b) Unit tests included with bug fixes helped to cover more related scenarios in addition to identified bugs.

c) Test team is more happy; unit test code snippets works as live spec document for them and help them to start testing right away.

d) Very few complaints from test team about missing or outdated specs.

e) Test team is very active in finding corner cases, fault injection, stress, perf scenarios and helped to provide better coverage and repro, which definitely improve the overall quality in eraly product cycle.

e) Writing the unit test for happy line scenario help us to exercise our scenarios as a real API user customer. This helps us to find API naming and usabilty issues even before including the public API in product.

f) We did keep test code and product code in separate assemblies, this helped to improve overall debuggability of the code.

Overall I found the approach was very practical and beneficial for us, I will post more details and some quantitative data later.

This posting is provided "AS IS" with no warranties, and confers no rights

Use NetworkInformation classes to get the list of listening ports on your machine

adarshk — Mon, 14 Mar 2005 19:01:00 GMT

.Net frameworks 2.0 have new addition of Namespace, System.Net.NetworkInformation, it provide a number of interesting classes to extract the network related statistics and state of the machine, it pretty much provide most of the functionality which is exposed by native IPHelper APIs.

Earlier I had shown a simple example for getting network availbility event notification. Here is another simple 4 line example, where your application could check all the listening ports on the machine.

using System;
using System.Net;
using System.Net.NetworkInformation;
public class Test
{
      public static void Main()
      {
            IPGlobalProperties ipGlobal = IPGlobalProperties.GetIPGlobalProperties();
            IPEndPoint[] connections = ipGlobal.GetActiveTcpListeners ( ) ;
            foreach(IPEndPoint ipe in connections)
           Console.WriteLine("Listening IPEndPoint = "+ipe.Port);
      }

}

Does your application require customizing System.Net.WebPermission, SocketPermission or DnsPermission settings?

adarshk — Mon, 06 Dec 2004 09:43:00 GMT

.Net frameworks comes with deefault security settings where components running under Intranet, Internet Zone can only have WebPermission to connect back to the server, from where they are downloaded. Also the component from Intranet zone and Internet zone don't have any SocketPermission and DnsPermission by default.

I am trying to find out some real world usage scenarios, where people are customizing these security settings for there application or components in either intranet or internet zone deployment. Special interest is WebPermission, SocketPermission, DnsPermission or NetworkInformationPermission (NetowrkInformationPermission is only in .net frameworks 2.0).

If you are one of them, please drop your comment about scenario and your experience with it.