Maintainability is an important factor in every software project. The costs of not getting it right run high. In fact, it is estimated that maintainability costs are often 70%-80% of a total project cost.

The main principle of maintainable code is to design loosely-coupled components with small number of connections to other functions. Factors such as solid Object-Oriented Analysis and Design (OOAD) and design patterns impact long term code maintainability.

Diomidis Spinellis [1] lists other important factors that affect maintainability. Among these factors are analyzability, consistency, length of expressions, functions, and methods, locality of dependencies and type checking.

If data abstraction is a policy promoting (among other things) a system’s stability and maintainability, type-checking is the enforcement mechanism. An implementation that takes advantage of a language’s type-checking features will catch erroneous modifications at compile time; an implementation based around loose types or one that circumvents the language’s type system can result in difficult-to-locate runtime errors.

The above statement while valid for stongly-typed languages like Java and C#, is falling short for dynamic languages. The simplicity and the dynamic nature of weakly-typed languages can not only be liberating during initial implementation, but can also have positive impact for long-term maintainability. For example, applications will no longer need big XML configuration files, because changes to the source code will not require recompilation. There are other substantial advantages of weakly typed languages as well [2].

Let’s take an example. In Groovy the entire language is based on weak types. Some argue that strong type checking at compile time helps more bugs to be caught early in the process. I agree with that in general. But the code simplicity that Groovy brings to the table and the whole notion of merging compile-time and run-time can also be seen as an important factor contributing to its long-term maintainability. According to the classical type checking principle, none of the Groovy code can ever be considered maintainable. I think this principle needs to be revisited for the age of weakly-typed scripting languages. What do you think?

References:

• [1] Code Quality: The Open Source Perspective, Diomidis Spinellis, Addison-Wesley Professional (April 3, 2006)
• [2] Choosing a Java scripting language: Round two, David Kearns, JavaWorld.com, 03/14/05

I ran across an interesting article entitled “Improving Test Coverage of Ajax Applications” in which the author likens the challenges of testing Ajax applications to that of testing traditional GUI apps. While some newer frameworks (like Selenium) are positioned to actually verify Ajax-ian behavior, they can lead to a false sense of security because of the complexity associated with the combination of actions in using a GUI.

While Ajax applications are definitely more snazzy than traditional web apps, because they can alter the traditional notion of page flow, one must put some extra thought into how the application will be verified.

David Rubinstein, of SD Times, has published an excellent editorial entitled “Taking to Testing” in which he summarizes a Web seminar where developer testing was addressed. He specifically writes that the benefit of testing during coding (as opposed to after things are complete)

is more value from the business system being delivered. If ROI is a function of a system’s cost to develop versus the value it delivers to the business, lower development costs translate to higher value.

Well said, Mr Rubinstein.

Let’s face it, JUnit has become the de facto standard for Java technology testing. Sure there are other powerful test frameworks (TestNG!), but they’ve never enjoyed the broad acceptance JUnit has, especially since the ingenious new version was released last year.

Andrew Glover recently published a tutorial: Jump into JUnit 4. A supplement to his popular “In pursuit of code quality” series, the tutorial published by IBM developerWorks guides you step-by-step through the fundamental concepts of JUnit 4, with emphasis on the new Java 5 annotations.

At the conclusion of this one-hour tutorial, you will understand the major changes to JUnit 4, as well as being familiar with features such as exception testing, parametric testing, and the new flexible fixture model. Last but not least, you will know how to do the following:

* Declare a test
* Use annotations to logically group tests prior to running them
* Run tests in Eclipse 3.2 or Ant, as well as from the command line

Check out the tutorial here and don’t miss the accompanying discussion forum for assistance with code metrics, test frameworks, and the creation of quality-focused code.

In the fourth edition of the Stelligent Early Quality Podcast Series, Paul Duvall and Levent Gurses discuss how Continuous Integration can be simplified with two popular tools: CruiseControl and Maven 2.

If you’re looking to intensify your CI and testing process or are curious about how these tools can help, this podcast is a valuable resource.

Also, check out the other editions in the series. Each podcast is about 5 minutes and each feature an informal conversation between two or more software professionals on technologies and solutions relating to early software quality.

Boo provides the ability to script with a more expressive language in NAnt build files via the boo task. As an example of the possibilities of what you can do with Boo in NAnt, check out the following two tasks, which first runs FxCop and then reads the output of a FxCop task so as to summarize the number of Critical Errors in FxCop’s result file.

<property name="fxcop.xml"
             value="${build.dir}bin${build.config}fxcop.xml"/>

<target name="fxcop" depends="build">
 <fxcop>
  <targets>
   <include name="${build.dir}bin${build.config}${library}" />
  </targets>
  <arg value="/out:${fxcop.xml}" />
 </fxcop>
</target>

<target name="fxcop-analysis" depends="fxcop">
 <boo>
  import System.IO
  fpath = Project.Properties['fxcop.xml']
  numerror = 0
  using input = File.OpenText(fpath):
   for line in input:
    if line =~ /Level="CriticalError"/:
     numerror++

  print("There were ${numerror} Critical Errors")
 </boo>
</target>

The fxcop-analysis target grabs a reference to the fxcop.xml property and uses Boo’s easy IO processing to read the file’s contents. Boo’s built-in handling of regular expressions makes finding the number of occurrences of critical errors a snap too.

XML by itself is fairly limiting when it comes to expressing behavior; however, with the addition of Boo or even the extensibility provided by creating custom tasks, you can add a higher level of functionality. Plus, with Boo, the level of effort is frighteningly low!

If you want to modify your team system project, you really need to get comfortable with the process template.

You can download a template editor from http://www.imaginets.com.

Once you’ve got the template editor, your first step is to download either the Agile or CMMI default process template to your local machine.

On the tool bar within Visual Studio, go into the Team menu, Team Foundation Server Settings, Process Template Manager. Choose your template and click download. This automatically creates a folder and the xml template is inside the folder.

Next, go into the Process Template Editor, click open, navigate to where you downloaded the default template and click open.

Now, let’s say you want to modify the workflow for tracking a bug.

Double-click on Work item tracking to expand the directory, then click on Work Item Type Definitions. You will see Bug, Task, Quality of Service Requirement, Scenario and Risk. Open the bug work item definition, click on the work flow tab and you will see there are 3 default values (Active, Resolved and Closed). Also, you will see there are 6 default transitions (from active to resolved, resolved to active, resolved to closed, active to closed and closed to active).

Okay, okay…Team Foundation Build has no built-in support for continuous integration, but even Khushboo Sharan, Program Manager, Visual Studio Team System acknowledges the advantages of Continuous Integration and explains how he sees Continuous Integration Using Team Foundation Build working.

Boo is statically typed language for the .NET platform inspired by Python– with Boo, you can write functioning .NET applications quickly. If you have a handle on Python or even VB, then picking up Boo is anything but scary. Boo has a host of features including built in Regular Expressions, collections, and closures; in fact, even though it is Pythonic in nature, it reminds me a lot of Groovy in that the language is unique to itself and not a cousin of some other language like Jython is Python or JRuby is to Ruby.

Recently, I found myself needing to script out some functional tests via Internet Explorer. I considered using Watir; however, I wanted to see what I could knock out with Boo due to its close integration with the Windows platform. As it turns out, Boo’s closeness to Windows makes IE automation so easy it’s almost…well, frightening. The only, err….terrifying aspect of using IE automation in Boo is learning mshtml, which isn’t as documented as one would like. Nevertheless, once you master a few of the common properties of HTML elements, you’re golden.

Here is an example of how easy it is to script out a simple test that verifies there are four comments for a particular blog entry interactively using Boo’s booish. One of the coolest features many scripting languages have is a shell in which you can interactively code behavior– this is superb for prototyping, experimenting, and generally learning a language’s features.

The test does a few thing along the way. First, an instance of IE is created, followed by a navigation to a website (www.thediscoblog.com). All hrefs are obtained– if the desired one is found, it is clicked.

>>> ie as duck =
 System.Type.GetTypeFromProgID("InternetExplorer.Application")()
System.__ComObject
>>> ie.Visible = true
true
>>> ie.Navigate2("http://www.thediscoblog.com")
>>> links = ie.Document.getElementsByTagName("a")
System.__ComObject
>>> site = "http://thediscoblog.com/2007/02/04/currying-maximum-..."
'http://thediscoblog.com/2007/02/04/currying-maximum-favor-with-groovy/'
>>> for link in links:
...     if(link.href.Equals(site)):
...             link.click()
...
mshtml.HTMLAnchorElementClass

Note how in the above code I must declare my ie variable as type duck. This is because of Boo’s statically typed nature– if I don’t force the duck-ness on my ie type then I wouldn’t be able to call the Visible property, as the lowest common denominator type, which would have been forced on the ie variable had I not said as duck, wouldn’t allow the Visible property call and would have yielded an exception.

Next, I obtain a list of all links in the resulting web page and proceed to iterate over the collection seeking my desired link. If it is found, I call the click method on the element.

With the next page loaded, I then grab a listing of all h3 HTML elements found on the page. If the id of the element (i.e. id=”comments”) is set to comments, I then assert that the text surrounded by the h3 tags contains the phrase “4 Responses” using a regular expression– which effectively tests the presence of 4 comments for this blog entry– if there are new comments, the assert will fail.

>>> h3s = ie.Document.getElementsByTagName("h3")
System.__ComObject
>>> for h3 in h3s:
...     if(h3.id.Equals("comments")):
...             assert h3.innerText =~ "4 Responses"
...
mshtml.HTMLHeaderElementClass
>>> ie.Quit()

Note how the assert keyword is built into the language as well– this is an example of Boo’s macros. Lastly, after asserting the presence of 4 comments, I proceed to kill the IE instance with a call to Quit.

As you can see, building out a simple acceptance test with Boo is a breeze– or should I say terrifyingly simple? Plus, using something like booish makes writing out simple tests a breeze. Watir is definitely a great choice for IE automation; however, with Boo, these tests (once written to a file) can be compiled into a native .NET dll, which can then be run via NAnt or even the command line with ease. How’s that for scary?