For any developer looking to test web services, there are a number of tools out there that seem to fit the bill. When you need one that allows you to interact and create functional and load tests with relative ease, soapUI is bound to be the tool you can’t live without.

To help get you started, Meera Subbarao has authored a how-to series on testing web services using soapUI. Published by JavaLobby and entitled, “Functional Web Services Testing Made Easy with SoapUI,” the series is broken up into three installments; with each article demonstrating an important soapUI feature that will make web services development easier for you.

Part 1 explores soapUI basics including how to write functional tests for your web services and how to add assertions to these tests. In short, soapUI emphasizes a good balance between simplicity and rich features and as Subbarao notes in Part 1,

Once soapUI has been downloaded and installed, you can have functional tests up and running in minutes.

For more elaborate programming tasks, Part 2 examines soapUI’s relationship with Groovy. Groovy is used in soapUI primarily for test setup, test teardown, and to decide which steps to start based on the results of the older ones. If you know Java, writing Groovy scripts with the UI will make your testing even easier.

soapUI also includes command-line utilities for running tests and mocks in a continuous integration environment so you’re able to run the test cases you’ve created within it and above all fail the build just like you would when any other unit test fails. Stayed tuned for the third and final part of this series which will cover integrating tests with your build tool, running these tests as part of your builds, and creating JUnit reports.

On the IBM developerWorks site, there’s a new tutorial demonstrating how to set up a Continuous Integration process. Authored by Andrew Glover, “Spot defects early with Continuous Integration” lays out a complete step-by-step guide to creating a best-of-breed CI environment using Hudson, Ant and Subversion. The resulting build process will run both tests and software inspections and will report back violations almost as quickly as they occur.

Thanks to the tutorial you’ll soon discover that Hudson is very easy to setup and get going. What’s more, even though the tutorial assumes Ant and Subversion as the build tool and repository, you’ll see that you can easily plug in Gant or Maven, CVS or ClearCase, etc.

For more articles addressing best practices for ensuring your code is the best it can be, check out the acclaimed “In pursuit of code quality” series or the accompanying discussion forum for assistance with code metrics, test frameworks, and the creation of quality-focused code.

Who cares about software metrics? As a Java developer, I do. Measuring certain aspects of my code lets me quantify my schedule, work effort, product size, project status, and code quality. Oh, and then my project manager cares too. If I don’t measure my current status (number of classes, dependencies to other modules, complexity, code coverage, defects as well as code smells - yes, we all know when we have code smells) and use the data to improve my code and my future work estimates, those estimates will just be guesses. And my project manager expects a little better than guesses.

Metrics is an Eclipse plugin that helps me take a holistic view of various aspects of my code. I use it on a daily basis to see how my project grows and if there are any deviations from the reference architecture. The plugin lets me take a closer look at:

• Number of Classes
• Method Lines of Code
• Number of Methods
• Nested Block Depth - Is nice, I like!
• Depth of Inheritance Tree - nobody wants to traverse a 16-node deep tree trying to find what they need. 1-5 maybe, but 16….too many levels…
• Afferent Coupling, Efferent Coupling - yea, whatever… we saw this here…same story…
• Cyclomatic Complexity - If my code is simpler than Paul’s does that make me look “simpler” too?
• …and more…

Quick Tutorial

1. Download and start Eclipse 3.2
2. Navigate to Help | Software Updates | Find and Install
3. Select Search for new features to install
4. Add a new remote site Metrics and point it to http://metrics.sourceforge.net/update
5. Finish the wizard and restart Eclipse
6. Download the sample solarsystem project from http://www.testearly.com/resources/agile/solarsystem.zip. Open the project in Eclipse. Note that this sample requires Java SDK 6.0.
7. Build the project
8. In the Package Explorer, right-click the solarsystem project and open the Properties dialog. Locate Metrics and check Enable Metrics
9. Rebuild solarsystem
10. Navigate to Window | Show View | Metrics | Metrics View
11. You are looking at a table of various metrics covering the solarsystem project
12. 
13. Feel free to dig down on each metric as it goes from source folder to package to class down to the method
14. Notice all metrics for this simple project are in blue and there are no exclamation marks in the source code indicating any problems. Let’s change that and make life difficult for ourselves.
15. Open the preferences page for Metrics and check Enable out-of-range warnings. Drill one level down to Safe Ranges, locate Nested Block Depth and enter 5 as the Max value. Similarly, enter 10 as the Max value for McCabe Cyclomatic Complexity
16. In a Java Perspective open PlanetUtil.java and add the following method:

    public void thisIsAComplexMethod() {
            if (true) {
                    if (false) {
                            if (true) {
                                    if (false) {
                                            if (true) {
                                                    System.out.println("This is a deeply nested if sequence.");
                                            }
                                    } else {
    
                                    }
                            }
                    }
            }
    
            if (true) {
                    if (false) {
                            if (true) {
                                    if (false) {
                                            if (true) {
                                                    System.out.println("This is a deeply nested if sequence.");
                                            }
                                    } else {
    
                                    }
                            }
                    }
            }
    }
    

17. Rebuild solarsystem and return to the Metrics View. You now see two red lines in the results table and an exclamation mark in the code editor. Clearly the new code failed the cyclomatic complexity and nested statements rules of Metrics and therefore was marked red. The cyclomatic complexity of the method is 11, while the if statements nest for 6 levels. Both values are out of the acceptable ranges we defined earlier.
18. 
19. Locate the Dependency Graph View icon in the Metrics View. It can be found on the upper right corner and it is denoted by four dots connected in a square. Click the icon to open the graphical dependency view of Metrics.
20. 
21. The packages in the project are denoted by boxes in different colors. Blue means normal relationship; red means cycles and orange denotes the selected node. There is also a circle in the middle, the tangle center, which displays the number of packages in a particular tangle and the longest walk. In general, the longer the walk the more layers are involved and therefore there may be refactoring opportunities. Similarly, the existence of red nodes and tangles indicates cycles in the package dependencies and that’s also something that may be avoided with a little care. Finally, every node and the tangle center provide right-click menus to drill-down for more details.
22. The reason for this tangle (cycle) is the JUnit test PlanetUtilTest, which is located in com.solarsystem.jupiter. Let’s do something about this.
23. In the Package Explorer, locate PlanetUtilTest, right-click and select Refactor | Move. Move the test into a new package com.solarsystem.test.jupiter.
24. Rebuild the project. Open the Metrics View. Click the graph icon. Everything should be blue. There should be no tangles. No tangle centers. Blue is better than red. Life is good…
25. 
26. Enjoy.

What does dependency analysis mean to you? To me it mostly translates to the fact that Common Services (CS) packages should not depend on any of their clients. Does that happen in practice? More than enough to make the case for dependency analysis.

Just like the other tools in this series JDepend can be used in Eclipse or as part of a Continuous Integration cycle. I like to see what’s going on in terms of dependencies and other architectural metrics all the time, so I use both. JDepend calculates:

• Total number of classes and interfaces - number of concrete and abstract classes (and interfaces) in the package is an indicator of the extensibility of the package. How many?
• Afferent couplings (Ca) - number of other packages that depend upon classes within the package is an indicator of the package’s responsibility. Who depends on me?
• Efferent couplings (Ce) - number of other packages that the classes in the package depend upon is an indicator of the package’s independence. Who do I depend on?
• Abstractness (A) - the ratio of the number of abstract classes (and interfaces) in the analyzed package to the total number of classes in the analyzed package. The range for this metric is 0 to 1, with A=0 indicating a completely concrete package and A=1 indicating a completely abstract package. How abstract I am? If I change today, how many of my dependents have to change with me?
• Instability (I) - the ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric is an indicator of the package’s resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable package and I=1 indicating a completely instable package. How stable am I? Do I change often?
• Distance to Main Sequence (D) - the perpendicular distance of a package from the idealized line A + I = 1. This metric is an indicator of the package’s balance between abstractness and stability. A package squarely on the main sequence is optimally balanced with respect to its abstractness and stability. Ideal packages are either completely abstract and stable (x=0, y=1) or completely concrete and instable (x=1, y=0). The range for this metric is 0 to 1, with D=0 indicating a package that is coincident with the main sequence and D=1 indicating a package that is as far from the main sequence as possible.
• Package dependency cycles - dependency cycles are reported along with the hierarchical paths of packages participating in package dependency cycles. If I depend on you and you depend on me, we have to work hard to adapt to each other’s changes, don’t we?

The JDepend4Eclipse plugin is an implementation of the JDepend tool. It follows the same principles and provides visual analysis inside Eclipse. One thing to note is that the plugin works on compiled java bytecode, so its important for your project to build. Related to this is the fact that if you’re following the same package/folder structure for your unit tests as your source code it might be a good idea to compile them into a separate output folder, separate all unit tests into another Eclipse project or just change the unit test package names (by appending the name test for example ), like I show below.

Quick Tutorial

1. Download and start Eclipse 3.2
2. Navigate to Help | Software Updates | Find and Install
3. Select Search for new features to install
4. Add a new remote site JDepend4Eclipse and point it to http://andrei.gmxhome.de/eclipse/
5. Finish the wizard and restart Eclipse
6. Download the sample solarsystem project from http://www.testearly.com/resources/agile/solarsystem.zip. Open the project in Eclipse. Note that this sample requires Java SDK 6.0.
7. Build the project
8. In the Package Explorer, right-click the source folder src/main/java and select Run JDepend analysis
9. In the newly opened JDepend perspective click on com.solarsystem.jupiter. Notice how the dependencies, packages with cycles, efferent and afferent dependencies and the metrics views get populated
10. Notice in the Dependencies view that the com.solarsystem.jupiter package has 3 Concrete Classes (CC), 1 Abstract Class (AC), 4 Afferent Dependencies (Ca) and 7 Efferent Dependencies.(Ce) Also the Abstractness (A) is 0.25 while the Instability (I) is 0.63. Finally, the Distance (D) to the main sequence is 0.11 which is denoted by a green dot in the Metrics view. Also in this view, notice that the package is marked as having a cycle. This is because the unit test PlanetUtilTest resides in the same package. JDepend works on compiled java code and therefore it picks up everything in the target/classes folder, including any unit tests. There is plenty of theory behind the various metrics gathered by JDepend and they are beyond the scope of this quick tutorial. It suffices to say that for any given package the shorter the Distance (D) to the main sequence, the better. In the above case the com.solarsystem.jupiter is used by four other packages, thus Ca=4. The package depends on 7 other packages, including junit.framework, therefore the Ce=7.
11. 
12. Generally speaking cycles between packages indicate complex interdependencies and should be avoided. In this step, let’s eliminate the cycles in the project.
13. In the Package Explorer locate src/test/java anc right-click on PlanetUtilTest
14. Select Refactor | Move…
15. Create a new package com.solarsystem.test.jupiter and click OK
16. 
17. Return back to src/main/java. Right-click and select Run JDepend analysis. All cycles are gone. While we eliminated the cycles, notice also that the distance jumped to 33 from 11 and is now denoted by a black dot.
18. In Java Browsing perspective select File | New | Interface. Enter a name, IBogus, select the package com.solarsystem.jupiter and click OK. This is just an empty interface.

    package com.solarsystem.jupiter;
    
    public interface IBogus {
    
    }
    

19. Build the project
20. In Package Explorer, right-click the source folder src/main/java and select Run JDepend analysis
21. Notice the Distance is now 16 and the dot turned green. But what did the IBogus interface add to the package? Nothing. It just fooled the tool. This is where special care must be taken. Sometimes emty or unused abstract classes can negatively impact the static analysis and make one belive that the package is in a better state than it actually is. My recommendation is to use other tools that detect unused classes and imports and get the whole system cleaned-up before each dependency analysis.
22. Enjoy.

If you use Eclipse for day to day Java development take a deep breath and relax. You are neither the first nor the only one. In fact, you are part of a growing community of Java developers in the world. SD Times recently reported that two-thirds of the enterprise software developers—66.3 percent—use Eclipse. This adoption rate is a success for an open source project, albeit supported by a giant like IBM.

The agile developers know that at the end it’s often not the tool that makes the difference. It’s the fundamental engineering practices. When the discussion goes beyond the tools it suddenly opens so many possibilities that even the most staunch tools proponents/opponents can sit down and unite in a common strategy. Let’s take coding standards for example. We all know that there are tons of tools for static code analysis and early defect detection. The Agile teams have choices in this matter. They can implement a set of static code analysis as part of their Continuous Integration (CI) cycle and get great reports the instant a potential bug gets checked-in. They can also encourage individual developers to use Eclipse plugins for code analysis and perform the same checks before they commit the code.

Two major plugins for code analysis in Eclipse are PMD and Checkstyle. Of course, Eclipse itself is also catching-up and it is constantly increasing its own set of code style checks. A look at Window | Preferences | Java | Compiler | Errors/Warnings reveals that the number and depth of the built-in code checks is fairly substantial.

Nevertheless, in this blog entry I would like to show you a quick example of how to setup and use Checkstyle for Eclipse .

Despite the fact that I use PMD and Checkstyle (and others for that matter, like Findbugs) in my daily projects, I favor Checkstyle for the following reasons:

• The integration of the tool to the environment seems to be tighter
• The rule customization and management in Checkstyle is way easier than PMD. I like!
• Checkstyle provides a few nifty features such as a pie chart depicting the distribution of problems
• Checkstyle comes with a richer set of predefined rules
• Better website documentation and easier learning curve

All and all Checkstyle makes my life easier, and especially after configuring a set of rules that make the sense for the project environment, it’s a workhorse! An added benefit of the custom rulesets is that they can be checked into the code repository, shared among the development team and reused in the CI static analysis phase. The latter can be achieved through integrating tools such as CruiseControl, Maven and Ant with the respective Checkstyle plugins. This brings a unified coding standard to the entire development team.

Quick Tutorial

1. Download and start Eclipse 3.2
2. Navigate to Help | Software Updates | Find and Install
3. Select Search for new features to install
4. Add a new remote site Checkstyle and point it to http://eclipse-cs.sourceforge.net/update
5. Finish the wizard and restart Eclipse
6. Create a new Java project, checkmeup
7. Add the following Java class:

   public class CheckMeUp {
      public void thisMethodShouldHaveAShorterAndCoolerName(String WHYALLCAPS, int g) {
         if (true) {
         }
         else {
         }
   
         while (true) {
            String x = "The white fox jumped over the red rabbit, which in turn jumped over my yellow submarine.";
            String y = x + "...";
         }
      }
   }
   

8. Build the project
9. In the Package explorer right-click on checkmeup and select Properties | Checkstyle
10. Check Checkstyle active for this project and select Sun Checks (Eclipse) - (Global) as the ruleset
11. Navigate to Window | Show view | Other…
12. Select Checkstyle | Checkstyle violations
13. Notice the 27 violations in this simple Java class
14. Now, let’s play with the rules. Assume that you do not like the Line contains a tab character rule. The sample class has 12 of it. Navigate to Window | Preferences | Checkstyle and Click on New…
15. Select Internal Configuration, enter a name and description. Click Import… and navigate to ECLIPSE_HOME/plugins/com.atlassw.tools.eclipse.checkstyle_x.x.x and select sun_checks_eclipse.xml. This will import all Sun Eclipse rules for the new custom ruleset. Also note that Checkstyle will create a new custom ruleset xml file under WORKSPACE/.metadata/.plugins/com.atlassw.tools.eclipse.checkstyle/internal_config__xxxxxxxxxxx.xml. This file can be added into the code repository and shared among the development team. Click OK.
16. Double click the new ruleset. Click Whitespace and uncheck the Tab Character rule
17. Back in the project properties, select the new custom rule as your configuration
18. Click OK. The tab warnings are gone.
19. In the Checkstyle violations view click the chart icon in the upper right corner. This will open the pie chart view shown below

    

20. Enjoy.

For those who like juggling multiple tasks, Eclipse provides a great opportunity. Take developer testing for example. JUnit comes standard out of the box and the agile developer can literally start practicing Test Driven Development (TDD) right off the bat. As individual developers increase the number and detail of unit tests the team may want to know how much of the code base is actually being tested. This is where test coverage comes into the picture.

The agile teams practicing Continuous Integration gain insight of their test coverage through tools such as CruiseControl and Cobertura. Since test coverage reports are generated as part of the CI cycle, the latter two provide an aggregate view of the test coverage of the entire code base. The reports, while open to the entire team, are mostly analyzed by the architects or project managers who would like to gain insight of the team’s coverage and trends.

Individual developers working with Eclipse can also gain the same insight into their test coverage without having to commit changes and wait for the CI server to complete the build. Coverlipse is an Eclipse plugin designed to measure the test coverage of Java code. It’s fully integrated into the Eclipse environment and allows the agile developer to see which parts of the code are actually tested. The ability to see test coverage immediately provides the shortest path to knowing what each developer’s individual test coverage is, even before a single line of code is committed to the repository.

Quick Tutorial

1. Download and start Eclipse 3.2
2. Navigate to Help | Software Updates | Find and Install
3. Select Search for new features to install
4. Add a new remote site Coverlipse and point it to http://coverlipse.sf.net/update/
5. Finish the wizard and restart Eclipse
6. Create a new Java project
7. Add the following Java class:

   public class NumberComparator {
     public NumberComparator() {
       super();
     }
     public boolean isGreater(int pFirst, int pSecond) {
       if (pFirst > pSecond) {
         return true;
       }
       return false;
     }
   }
   

8. Add the following JUnit test case:

   import junit.framework.TestCase;
   public class NumberComparatorTest extends TestCase {
     public void testIsGreater() {
       NumberComparator nComp = new NumberComparator();
       assertTrue(nComp.isGreater(5, 4));
     }
   }

9. In the Package Explorer, right-click on NumberComparatorTest and select Run As | JUnit w/ Coverlipse
10. Wait for the test to complete
11. Open the NumberComparator class. You should see the Coverlipse markers as in the following picture:
    
12. Notice the red mark on the left. This indicates that part of the method is not covered by the unit test.
13. Add a second assert to the JUnit test case as follows:

    assertFalse(nComp.isGreater(5, 6));

14. Rerun JUnit w/ Coverlipse
15. Notice there are no red marks now as the entire code is covered

In the latest “In pursuit of code quality” installment, entitled “Programmatic testing with Selenium and TestNG”, author Andrew Glover provides a tutorial on user interface testing with Selenium, an open-source Web user interface testing framework that drives a user’s Web browser when performing tests.

While programmatic testing isn’t for everyone (non-developers will likely prefer Selenium’s Fit-style tables), it does give you access to TestNG’s exceptional flexibility….

TestNG is an especially good match for Selenium because it enables you to do some things that aren’t possible using other frameworks, such as test using dependencies, rerun failed tests, and set up parametric tests with the parameters defined in separate files.

…. and also allows you to build out your test framework with DbUnit and Cargo, thus ensuring the logical repeatability of your tests.

Don’t miss out on the code quality discussion forum where you can learn first-hand about code metrics, test frameworks, and writing quality-focused code.

FitNesse, a popular Web-based test and collaboration server, is an enhancement to Fit (Framework for Integrated Testing) and an
invaluable way to collaborate on complicated problems early in development.

In January, Gojko Adzic published a free tutorial (PDF) ‘Getting Fit with .NET’ to get you on your way to testing .NET applications with FitNesse.

Available online and updated last month to cover Fit.NET 1.1 including a new chapter on DoFixture, working with arrays and business objects, topics include:

• Setting up a FitNesse server for testing .NET code
• Writing basic tests, performing common tasks
• Tips and tricks for writing better tests and making test pages easier to read
• Managing content with FitNesse
• Organizing tests into test suites
• Most important differences between .NET and Java versions

Definitely check it out if you’re considering using (or already are using!) FitNesse in your projects.

In related news - Adzic has also released DbFit, an extension of the Fit testing framework which allows database developers to write and automate functional and acceptance tests easily. Accompanying the first version of DbFit is ‘Getting Fit With Oracle’, a short introductory guide for test-driven Oracle database development using FitNesse and DbFit.

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.

This past summer, James Bach, a well-known name in software testing, was invited to speak at Google on the subject of “Becoming a Software Testing Expert” - the video presentation is about an hour long (and the screen is a little fuzzy) so you may want to read the slides in PDF form.

Either way you view it, the tutorial is ideal if testing is your career or if you’re interested in how Bach became an expert in the industry. In the end you’ll come away with a better understanding on what it means to think like a tester and how to design and critique testing practices (rather than just copy what the “gurus” tell you to do). You’ll also get self-study strategies and methods for developing a colleague network.