Freigeben über

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

  • Artikel

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

Comments