aspose file tools*
The moose likes Testing and the fly likes Automated Defect Prevention Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Automated Defect Prevention" Watch "Automated Defect Prevention" New topic
Author

Automated Defect Prevention

Azad Bajaj
Greenhorn

Joined: Oct 25, 2007
Posts: 6
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
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30913
    
158

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Jan Cumps
Bartender

Joined: Dec 20, 2006
Posts: 2510
    
  10

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


OCUP UML fundamental and ITIL foundation
youtube channel
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30913
    
158

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
Greenhorn

Joined: Oct 25, 2007
Posts: 6
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
Greenhorn

Joined: Oct 25, 2007
Posts: 6
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
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30913
    
158

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
Bartender

Joined: Dec 20, 2006
Posts: 2510
    
  10

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
Greenhorn

Joined: Oct 25, 2007
Posts: 6
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Automated Defect Prevention