There is an interesting discussion on artima.com relating to code metrics and their usefulness. The discussion focuses heavily on JDepend and the data it reports as elaborated in DevWork’s “Code quality for software architects.”

The fourth article in IBM developerWorks’ series “In Pursuit of Code Quality,” “Code quality for software architects” examines how to use coupling metrics to support your system’s architecture.

Most well-designed software architectures are intended to support a system’s extensibility, maintainability, and reliability. Unfortunately, inattention to quality issues can easily undermine a software architect’s best effort. There are a number of coupling metrics; two interesting examples that signify an architectural maintenance issue are Afferent Coupling and Efferent Coupling. These examples along with other architectural metrics will help you monitor, maintain, and correct the code quality of your software architecture.

Check out the “In Pursuit of Code Quality” series and feel free to engage in the “Improve your Java Code Quality” discussion forum for feedback, questions, or to post your own comments!

Can automated testing really replace all manual testing? Software development strategies such as Agile methods are highly committed with the idea of devoting a large part of an organization’s testing resources, if not 100%, to automated testing. Jonathan Kohl reflects on this “over-automation” debate in his blog entry about the risks of Reckless Test Automation.

This controversy isn’t new news - for years the software industry has been trying to understand what constitutes Agile methods such as Extreme Programming (XP). The idea that all tests should be automated continues to saturate the industry. Yes, there are some clear benefits of test automation. Tests can be run faster, they’re consistent, there is less overhead, the quality assurance cycle is presumed shorter. Kohl does point out that test automation will truly deliver, however some amount of manual ad-hoc testing is the supplement needed to fill in the holes.

I agree with Kohl’s outlook - although I don’t necessarily agree that every member of the Agile community is enthusiastically supporting the 100% automation methodology. Automated unit tests and functional tests have great value and are a cornerstone of many agile development methods but this is just a small part of the overall testing effort. In instances where you’re only going to run the test once or twice tests are better suited for manual execution.

In the end, it really comes down to the appropriate choice of tools, techniques and approaches for the test at hand. The moral of Kohl’s story is that sometimes there is just no substitute for simple human involvement with a product. Every software development shop needs to find a good balance between both automated and manual testing, if you go too far in either direction, the results will be reckless.

TestDriven.NET is a freely available tool which makes it easy to run NUnit developer tests with a single click, anywhere in Visual Studio solutions. The tool can be found at http://www.testdriven.net.

With the tool installed, once a NUnit test case has been defined, simply right click and select the Run Test(s) item and TestDriven.NET will run that test only. TestDriven.NET also supports running tests are different aggregation levels depending on where one right clicks.

This is a handy tool worth downloading!

In large integration environments, simulators can drastically improve the testing process. Constructing simulators, however, is another development task that takes up precious time and resources. Using a dynamic language like Groovy, conversely, can facilitate the quick creation of working simulators in a matter of hours.

For example, imagine a B2B environment where various partners communicate in a hub and spoke model. A partner sends an XML document, which eventually reaches a receiving party, who in turn responds with an acknowledgement. System testing in this architecture is challenging at best; however, if the interfaces between partners has been established (think XML documents), then stubbing out various partners becomes a simple task of creating a simulator to accept XML and respond with the corresponding acknowledgement.

Groovlets are essentially servlets written in Groovy; however, they are much much easier to construct. There is no need to extend a base class- just create a simple script and drop it into a configured container and things works like magic. Groovlet’s have implicit access to the Request and Response objects, in addition to a few other common Servlet specification objects as well. What’s also impressive about utilizing Groovy in this situation is how incredibly easy it is to do mundane things, such as parsing XML, manipulating web requests and responses, and rapidly deploying modifications.

Parsing an incoming XML request is a matter of employing Groovy’s XmlSlurper utility, which facilities accessing data in an XML document via GPath (think XPath).

The following incoming XML needs its SesssionID pulled out and applied to a response document:

<?xml version="1.0" encoding="UTF-8"?>
<ziIOW xmlns:ds="http://www.acme.org/8303...">
 <ziHeader Version="1.4">
   <Service Version="1.4" Name="BILL_PAY">
    <TimeStamp>2001-12-17T09:30:47.0Z</TimeStamp>
    <UUID>8983933-OIO-893111</UUID>
   </Service>
   <Request>
    <VendorID>905RTE3</VendorID>
    <BizID>E32R</BizID>
    <SessionID>MV_8934_KER</SessionID>
   </Request>
 </ziHeader>
 ....
 ....
 </ziIOW>

Grabbing the XML from the incoming HttpServletRequest and obtaining the SessionID couldn’t be any easier:

def xml = request.getReader().getText()

def doc = new XmlSlurper().parseText(xml.trim())
def sessionid = doc.ziHeader.Request.SessionID.text()

Note how in Groovy, a normal Java IO Reader object has a new method on it: getText(). This makes IO incredibly simple!

Next, a canned response is generated, which requires a unique UUID and the same SessionID of the request. As this is a simulator, the rest of the XML response, which would undoubtedly be important in a live environment, is static.

Generating a unique id is straightforward via Java’s Random class and a healthy usage of Groovy’s String substitution ability (aka GStrings):

def rndm = new Random(new Date().getTime())
def ruuid = "sim_grv_${Math.abs(rndm.nextLong())}"

Obtaining the canned response also utilizes Groovy’s GStrings via the ${value} syntax:

def getXMLResponse(uuid, sess_id){
  return """<?xml version="1.0" encoding="UTF-8"?>
   <ziIOW xmlns:ds="http://www.acme.org/8303...">
     <ziHeader Version="1.4">
      <Service Version="1.4" Name="BILL_PAY_RESPONSE">
       <TimeStamp>2001-12-17T09:30:47.0Z</TimeStamp>
       <UUID>${uuid}</UUID>
      </Service>
      <Request>
        <VendorID>905RTE3</VendorID>
        <BizID>E32R</BizID>
        <SessionID>${sess_id}</SessionID>
      </Request>
     </ziHeader>
     ...
     ...
     """
}

Note, the meat of the XML isn’t shown as its static; hence the … in the code above. Also note the usage of Groovy’s """ synatx for multi-line Strings. Via the """ synatx, escaping isn’t required, which helps in using XML in Strings.

Finally, the XML response is sent back to the sender:

def xmlres =  getXMLResponse(ruuid, sessionid)

def responseout = response.getOutputStream()
responseout.print(xmlres)

Because this Groovlet is a simple script living in a web context, if modifications are necessary, it’s quite easy to change things locally and redeploy the script, not the entire war file.

The hardest part in building a B2B simulator in Groovy is determining the interfaces involved (i.e. the incoming request XML and outgoing response XML) and what pieces of data must change. Once those are understood, coding a working B2B simulator in Groovy takes minutes!

For most people, quality concepts such as code complexity, test coverage, and source duplication are easy to comprehend. But the idea of making code “defect resistant” might not be implicitly clear.

Perhaps it is because the phrase “defect resistant code” really addresses more than just the code itself: it is a collection of practices, processes, coding metrics and technology infrastructure. These are all combined to make it difficult for a developer to introduce a defect into a code base.

At Stelligent, we often talk about the “lifetime” of a defect. All software professionals understand that defects will be introduced during development. The question we like to ask is, “How long will that defect live in your source management system?”

Effective organizations find ways to shorten that lifetime of a defect by using a combination of developer testing, automated analysis frameworks (that extract and report on factors such as code complexity and test coverage) and an automated testing and build framework (that builds and exercises unit tests with every material source code change).

The result is that code containing a defect will trigger a series of events that immediately communicate to the developer (and team) that a defect has been introduced.

Maybe it uses a little literary license to declare the “code” itself to be defect resistant. But the result of this collection of practices, coding techniques and automated processes does have the effect of making it difficult to add new defects to the existing code base.

All organizations that develop software should view their source code as an asset that should be protected. A great way to protect code assets is to prevent defects from impacting their stability and tolerance to change.

Organizations that make their code “defect resistant” improve their ability to efficiently deliver reliable, effective and high-quality software solutions.

Developer testing EJB applications can be best described as challenging. Due to the managed nature of EJBs, extensive fixtures are required for container configuration, deployment, and database seeding. Thankfully, there are a number of frameworks available to elevate some of the burden.

Check out these useful resources:

• Container Driven Testing: Advanced EJB Testing with OpenEJB (TSS, June 2004)
• Testing EJBs with Cactus
• A lightweight nonintrusive EJB testing framework (JavaWorld, Nov 2004)
• JUnitEE Tutorial
• Streamlining Your EJB Tests with MockEJB (dev2dev, Oct 2005)
• Execute EJB JUnit Tests in Your Deployed Apps (DevX.com, May 2005)

Johanna Rothman, questions “How Much Building is Too Much?” in a recent article in StickyMinds. In it, she clearly seems to take the position that, for most projects, the more often you build your software, the better. I very much agree and I’d also like to address a few points a reader makes on this topic.

How often you build may be based on the needs and culture of your project. I wouldn’t always suggest that a project immediately move from never building their software to Continuous Integration (CI) - building at every change to the SCM. A more incremental approach to CI may work for effectively in gaining acceptance in the group. One of the readers indicated that:

One of the biggest issues we had with frequent builds is that it encouraged poor development practices and poorer requirements definition.

I highlight this because I’ve heard this before as an excuse for not performing frequent builds. I’d suggest that ineffective programming practices, not building frequently, had everything to do with these problems. In this case with frequent builds, they were simply finding out sooner that there were problems with the software. This is actually a good thing; By using this feedback effectively, you can spend time on integrating quality practices into the group, such as writing automated tests, performing reviews or pairing, and/or running software inspection tools to highlight deficiencies.

Rothman also makes a good point that the testers serve a specific function and it is not feasible to have a tester test every build in an environment that performs frequent builds. There may be discussion amongst the development team on which builds the testers will focus their efforts.

Finally, remember that you should script every part of your build process so that you can execute it early and often. If you don’t have a repeatable way to build or test your software, there isn’t much else matters.

Mary Jo Davis, editor of Ziff Davis, has written an interesting article in eWeek about the delay of Windows Vista due to quality. Annoyance has been stirred in a very long series of disappointing announcements surrounding Microsoft’s new operating system, revolutionary features have been dropped, so why the recent delay from Fall 2006 to January 2007?

Jim Allchin, Co-President of the Platforms and Services Division, said in a conference call in March, that he would not release Vista if the operating system did not reach a standard of quality, especially around security, drivers and performance, with which he was comfortable.

Reportedly, the quality issue in Redmond has been raised across all divisions inside Microsoft. In fact, Microsoft has pledged to re-engineer software development with an internal project named Software Quality Metrics or SQM. Although information on SQM is limited sources say that it consists of tools to measure the performance of various product components including software reliability, quality of service and usage.

Vista has already suffered several postponements; perhaps the implementation of SQM will keep them on track for the future release.

In his encouraging article, “Quality is Now Development Job One,” technology editor Peter Coffee reports the highlights of a roundtable discussion organized by eWEEK Labs about the importance of quality assurance, over time deadlines, throughout the software development life cycle. Shipping today, with unknown defects, just to meet a release date is only leading to harm for the company, the consumers and its partners.

The article describes that fixing defects consumes 80% of software development costs. Why not monitor the quality of software now instead of spending more money, having a poorer system and not delivering what was proposed? The market lifecycle and the presence of Open Source vendors dictate that quality has to be high to survive.

Segue Software’s Ian MacLeod expressed his wish for extensive industry adoption of tool integration, noting that “Quality is all the elements of the ecosystem–requirements, development and test management, defect management, monitoring, and diagnostics across the deployment line and into operations.”

In other words, the development process needs to be improved – more QA, whether it is with tools and/or services, would result in less expensive testing efforts, and less expense throughout the whole process.