JTest usage

I noticed that JTest got added to the description for this forum. Does anyone else use JTest? If so, at what point in the development process do you use it? What features do you think are most beneficial?

Quote from Parasoft's website:Jtest is a Javaunit testing and static analysis tool that automatically tests any Java class, JSP, or component without requiring you to write a single test case, harness, or stub. With the click of a button, Jtest automatically tests code construction (white-box testing), tests code functionality (black-box testing), and maintains code integrity (regression testing). User-defined test cases and stubs can be added as needed. Jtest also helps prevent errors with a customizable static analysis feature that lets you automatically enforce over 300 industry-respected coding standards, create and enforce any number of custom coding standards, and tailor the standards enforced to a particular project or group. By integrating Jtest into the development process, you can prevent software errors, increase code stability, and reduce testing time.

Just to clarify, I haven't used JTest, but based on the quote, I'd say there a two approaches to using JTest: 1) All of the time during the development process 2) Near the end of a project Guess 3 times which one I suggest...

Lasse, I do use JTest, so I'm familiar with their marketing (although I realize that wasn't clear from my original post.)

1) All of the time during the development process

Number one hits it right on the head. There are a few subcategories to number one that I know people use: a) After compiling, but before testing (if not doing TDD) b) After code works and before releasing code to repository c) Running automated daily or weekly d) When have time Looks like we need more than 3 guesses now Any ideas of which ones look best? My question isn't really JTest specific. It's more of when it is appropriate to look for static analysis violations.

Ah. I missed the "anyone else" part... I would say the best timing for running the tests depends on their execution time. As a general rule, I would run the tests after every compile. If the execution takes 5 minutes, it might be too long for some people to do it after every compile, so I'd look for ways to disect the test collection into two piles: run-these-after-each-compile and run-these-before-committing-to-version-control. How does that sound?

I agree with Lasse - getting feedback as early and often as possible is critical. I would run as many tests as possible before commiting my code to the repository - it's just not very constructive to pollute my coworkers sandboxes with *my* bugs...

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Lasse, Ilja: That definitely sounds like a reasonable way of looking at it. The dynamic analysis takes about two minutes (long enough to be disruptive to the train of thought), but the static analysis takes about thirty seconds. It sounds like it would be a good idea to do the static analysis often, perhaps while running my own JUnit tests and the dynamic analysis before committing to the repository. Thanks for the advice!

How long do your JUnit tests run? I typically find feedback from those to be the most valuable...

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

The unit tests that don't use the server, take less than a second. The ones that use the server take about 10 seconds each, plus the time to start the server. I am trying to write more unit tests that don't use the server. JTest runs any unit tests you have defined in the same package as the class under test. I could set up JTest to run the static analysis and my unit tests very often. For some reason the unit tests that JTest creates take much longer to run. Maybe because a lot of them throw exceptions.

Interesting. How often do the unit tests JTest automatically generates fail? For what reasons?

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Originally posted by Ilja Preuss: Interesting. How often do the unit tests JTest automatically generates fail? For what reasons?

It depends on how you code. They tend to fail often (at least until you get used to it) at the beginning because JTest tries to find error conditions. For example, it passes null as objects or object fields to a method. It also produces unexpected data (such as returning a String from a session when you are expecting an Integer.)

And what do you do to make that tests pass? Do you feel it does help you to produce better code?

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

To make tests pass: Usually I add checks for nulls or add design by contract commands to state that the method should not be passed in nulls in the first place. In terms of better code, I think it takes a while for the ideas to grow on me. But after this conversation, I think I'm there. Thanks Ilja! You asked some really helpful and thought provoking questions.

Originally posted by Jeanne Boyarsky: To make tests pass: Usually I add checks for nulls or add design by contract commands to state that the method should not be passed in nulls in the first place. In terms of better code, I think it takes a while for the ideas to grow on me. But after this conversation, I think I'm there.

So am I understanding you right that you feel adding the postconditions to your code makes your code better?

You're welcome - your answers are quite helpful and thought provoking to me, too! It's actually a topic I wonder about for some time now. (I know, I could just have tried it for myself - but there is so much else to try, too...)

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus