Automated Defect Prevention

[Azad Bajaj]

Hi,
Need some information on how can one implement ADP into existing project. More over i m pretty confused with ADP driven by tools or ADP driven by certain set of principles, policies and practices?

To drill it down i have simple situation:

Like there is a pop up screen on my webpage and this pop up screen gives an Error on the Webpage while submitting information on the pop up. After going into the code i discovered this Defect is due to Refresh function call for Web Page at the submit action of the Pop up Screen and refresh of the webpage sends some null value to some xyz method which throws an Exception.

Now to solve this bug i can simply remove the refreshing function on the Submit button of Pop up or some other code change. But this is again typical terminology of solving the problem. How can i prevent this from happening using ADP with all the possible tools and rules.

Azad Bajaj
[ October 25, 2007: Message edited by: Azad Bajaj ]

[Jeanne Boyarsky]

Azad,
Welcome to JavaRanch!

Need some information on how can one implement ADP into existing project. More over i m pretty confused with ADP driven by tools or ADP driven by certain set of principles, policies and practices?

Automated Defect Prevention is a set of principles/philosophies/etc supported by tools. The philosophy part comes from seeing one defect as an opportunity to eliminate all other defects of that type from occurring. In other words, we can set things up so we detect the problem before it becomes a problem. Tools are necessary for the automation part. A build tool is the hub since it runs the other tools/detections regularly. Other tools like JUnit, static analysis and custom rules detect the classes of errors.

Now to solve this bug i can simply remove the refreshing function on the Submit button of Pop up or some other code change. But this is again typical terminology of solving the problem. How can i prevent this from happening using ADP with all the possible tools and rules.

The first step isn't a tool. The first step is how can you express this bug verbally. Suppose you got a new developer on your team. What could you tell him to avoid doing so he didn't get hit with this error. For example, suppose that solution is not to use the code snippet <form onsubmit="window.location.reload();">.

Once you've identified the logical rule, you can figure out how to prevent it. In this example, you could add a JUnit test that reads in all the HTML/JSP/JSPF files and looks for that code snippet. Regular expressions are great for this. As you find more "bad" snippets, it is easy to add them to that JUnit test. When running the JUnit test with your build, you have a built in failsafe for any future code against having this error.

Sometimes, this is oversimplified. For example, suppose it is ok to reload the form on submission in certain cases. In this case, you can add exceptions to your JUnit test. These are cases that have been manually reviewed and proven to be ok in this situation. The extra human oversight gets you to do a more targeted code review in a situation that is more likely to have a bug than the average piece of code.

[Jan Cumps]

you could add a JUnit test that reads in all the HTML/JSP/JSPF files and looks for that code snippet.

There are two very nice projects on SourceForge:

PMD and Checkstyle. They are specialized in analyzing source code. Both of them allow you to write your own rules. They provide JUnit-like reports, and integrate with Ant and Maven.

Regards, Jan

[Jeanne Boyarsky]

Originally posted by Jan Cumps:
There are two very nice projects on SourceForge

Yes. I'd actually recommend using those starting when you have a second rule. The reason is that one likely needs approval to spend time setting up a tool and it is nice to have one rule to show how it can be useful first. For some reason, we don't need approval to write things ourselves!

[Azad Bajaj]

Automated Defect Prevention is a set of principles/philosophies/etc supported by tools. The philosophy part comes from seeing one defect as an opportunity to eliminate all other defects of that type from occurring.

Thanks Jeanne
knowing the philosophy part of ADP has made clear picture of ADP technology in my mind. As you suggested earlier.. about some tools.. i m upto evaluation of Jtest and EnerjyCQ2 so far.. Now here i just want to know whether the tools like checkstyle, findbugs, Emma, or PMD, or some static analysis tool and Certain tools which generate only Junit Tests are individually classified as automated Defect prevention tools???
If yes then how do we classify the tools like Jtest and EnerjyCQ2 which contain combination set of tools??

Coz i believe Static analysis is the heart of ADP technology so any tool which does not supports static analysis should not be ADP tool individually. Like tools for Junit or ANT.

[ October 28, 2007: Message edited by: Azad Bajaj ]
[ October 28, 2007: Message edited by: Azad Bajaj ]

[Azad Bajaj]

PMD and Checkstyle. They are specialized in analyzing source code. Both of them allow you to write your own rules. They provide JUnit-like reports, and integrate with Ant and Maven.

Hi Jan,
I have tried my hands on Checkstyle, its a good tool.. but m facing one problem i.e. inspite of enabling magic number error for my project i was not able detect the magic number errors using checkstyle. Can it be some version problem with Eclipse 3.3 and CheckStyle 4.3?

[Jeanne Boyarsky]

Azad,
We currently use Jtest for static analysis and Emma for code coverage. While JTest is a very powerful tool, our main reason for using it is that it was the only tool on the market a number of years ago when we bought it. It's expensive though and I think the open source tools can meet most common needs. If I was starting out with static analysis now, I would try PMD and checkstyle before buying something. Emma is an open source tool for code coverage. It's great and lightning fast!

Certain tools which generate only Junit Tests

I'm not a big fan of these tools. I prefer to handwrite my tests as they are more thorough.

Certain tools which generate only Junit Tests are individually classified as automated Defect prevention tools???
If yes then how do we classify the tools like Jtest and EnerjyCQ2 which contain combination set of tools??

I think the vendors have hijacked "automated defect prevention tool" as a buzzword. Just like tools say SOA that have nothing to do with it. I don't feel a need to classify tools; I'm more interested in their features. That said, JTest and EnergyCQ2 certainly support automated defect prevention.

Coz i believe Static analysis is the heart of ADP technology so any tool which does not supports static analysis should not be ADP tool individually. Like tools for Junit or ANT.

I don't think there is any such thing as one tool being the heart of ADP technology. Even if you could get all the tools in one (a build, junit and static analysis), there is still the non-technical aspects. In addition to the philosophical parts, there is also training new people on it.

I guess I'm trying to say, that just buying JTest or EnergyCQ2 are not ADP on their own. Neither is JUnit/TestNG or Ant/Maven. However, they each do some part of it. Ant/Maven prevents defects like compiler errors (and anything else you set it up for) from slipping through. JUnit/TestNG prevent regression defects from slipping through. And JTest/PMD/etc prevent coding standards defects from slipping through. There's nothing that makes a defect found by static analysis more significant than a compiler error. It's just that the build/unit test tools are open source and don't put so much marketing energy into it.

[Jan Cumps]

Originally posted by Azad Bajaj:


Hi Jan,
I have tried my hands on Checkstyle, its a good tool.. but m facing one problem i.e. inspite of enabling magic number error for my project i was not able detect the magic number errors using checkstyle. Can it be some version problem with Eclipse 3.3 and CheckStyle 4.3?

I'm not using eclipse, so can't advise you on this one. I use it with Ant, and I'm able to configure Checkstyle as described in their documents.

Maybe it's a good idea to first try and get it working without exlipse, and integrate when you got it up and running.

Regards, Jan

[Azad Bajaj]

Thanks Jeanne and Thanks Jan .. The information shared by you guys had been a great help. Will come up soon with new findings and ADP tools and new questions if any.

Thank you,
Regards,
Azad Bajaj