Wednesday, February 24, 2010

Testing as a Concern

I was asked a question about unit testing based on this code:

   1: protected void Page_Load(object sender, EventArgs e)
   2: {
   3:     logger.Info(@"Loading the AgentDetails 
   4:         page");
   5:     
   6:     this.InitialiseRequest();
   7:     this.SetHeaderTabs(HeaderTabs1, 1);
   8:     
   9:     logger.Info(@"Webservice method 'getAgentDetails' 
  10:         is called from the Web References layer");
  11:     
  12:     WSLayer.AgentDetails agtDet = this.WebService
  13:         .getAgentDetails(this.AgentCode);
  14:  
  15:     this.AgentName = agtDet.Subagent[0].Fullname;
  16:     this.SetTitleBar(HeaderTitleBar1);
  17:     this.SetAgentDetails(AgentDetails1);
  18:  
  19:     logger.Info(@"End of Loading the AgentDetails 
  20:         page");
  21: }

Here is the question - “Can I write asserts inside this block itself?”. And a great tremor was felt in The Force.

From Wikipedia:

In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity of programming and encapsulation (or "transparency" of operation), with the help of information hiding. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).

For those who are unfamiliar with this concept, it is a far reaching design guideline that can help us create code that adheres more effectively to the SOLID design principles. It also forces us to keep our code focused on the underlying behavior of each concern and to make better choices about how each concern will interact.

There is, however, one area that is never discussed in terms of its being a “concern”, but should be - testing. The same level of effort should be applied to testing (and by this I mean unit testing), as to the design of a UI or data access layer. In fact, the amount of time spent on testing should be more than any other concern, as it applies to all other concerns. This also means not putting debug code into your production code. That is a concern of testing, and should be treated as such.

We must raise testing to the same status as any other concern and treat it with the same level of dedication, discipline, and respect.

No comments:

Post a Comment