DBC in Jtest

[Bhanu Vijaya]

Hi ,
I am using Jtest as the unit testing tool for my project.Now in the process ,i am planning to use design by contract language which Jtest supports.But to use it i have a big question in my mind.How does the DBC specifications affect my coding? I mean if i say, in the precondition some (object != null) and some (object.attribute > 50) in my pre-condition , do i need to again validate for these in the code ? Well lets say it does not make sense because Jtest will process the DBC and verifies these things.But when my code goes to production,there will not be anyone to check on these things and if such a kind of bad input comes, my code will not work right ? Its something like sailing without life jacket!
So in a gist my questions would be
a)At what point of coding is the DBC used ? Can it be used in Maintenance/enhancements ?
b) And does using the DBC help in reducing coding efforts like validations e.t.c(I mean does the same pre-condition need to be validated again in the code ).
Kindly guide me.

[Jeanne Boyarsky]

Bhanu,
You are using JTest in addition to your programmer written unit tests, right?

a) It's probably easiest to start using DBC on new code (or limit yourself to a few classes or a package) at first. That way, you can get a feel for it, without being overwhelming.

b) It depends on how the code is being called. If you are only calling it from some trusted code, you can have less validations (but you still need some.) If it is a library, you need thorough validations. The DBC comments are for JTest. They aren't enforced at runtime.

[Bhanu Vijaya]

Jeanne,
Thanks for the clarifications.
So DBC comments are used just like FYI in the code.They do not affect(decrease) the coding effort in terms of quantity but might be helpful in terms of quality as the contracts specify clearly what is the input and whats the output.
Now my team mates are questioning me , its an extra effort being put ( thinking about Pre,post and invariant conditions , writing DBC comments using $implies,$result in pre,post and invariant tags , following the DBC syntax rules) in addition to the coding effort.
So is the DBC used only for clarity(coding and the code maintenance later) and nothing else??
Thanks for ur time,
Bhanu

[Ilja Preuss]

Originally posted by Bhanu Vijaya:
its an extra effort being put ( thinking about Pre,post and invariant conditions , writing DBC comments using $implies,$result in pre,post and invariant tags , following the DBC syntax rules) in addition to the coding effort.

That's a naive fallacy: If you want your code to work, there simply is no way around thinking about pre- and post-conditions and invariants. Writing them down in a formal language (in the code) will just help you to think about them and, of course, document them for later maintenance (for example, for the change you need to do tomorrow...).

Of course using DBC is not the only way to do this. Some years ago I used to write JavaDoc comments for all my classes before implementing them. That helped me very much to think about what my classes should actually do.

Today, I write unit tests instead (using test-driven-development). I also know some people who use a combination of DBC and TDD.

With other words, saying that DBC is an extra effort is like saying that looking at the map is an exta effort in addition to driving from A to B. Looking at the map is only wasted if you don't care about where you actually arrive...

[Bhanu Vijaya]

Thanks Ilja.Those were indeed nice assertions ! )..I will implement the DBC now in my project.If you could let me know any site/book where there is java code with DBC implemented in it, i would really appreciate that ! Coz our with our MVC type project we have so many layers of classes and we would like to know how effectively DBC can be implemented to improve the code quality !

[Jeanne Boyarsky]

Bhanu,
The type of DBC you are using depends on why you are using DBC. If it is merely to get JTest to pass, you are more limited in what you need to document. (@pre and @invariant are the most common case) If it is because you are really interested in doing DBC, you need the more complex tags.

I agree with Ilja that you need to think about this stuff anyway. But it is somewhat easier to start with a limited set until you get buy-in.

[Jeanne Boyarsky]

Bhanu,
Also, there are some examples of DBC in the JTest documentation.

[Bhanu Vijaya]

Jeanne ,
Well i have seen the examples in Jtest but they are merely like HelloWorld stuff ! And moreover when i run Jtest thru my files , everytime its giving is a null pointer exception for which i need to put a @pre as (object!=null).Well for every method "@pre object != null and @post $result != null " ..these are the only tags i need to put for Jtest to pass my file !Is this ok ?

Thanks,
Bhanu

[Jeanne Boyarsky]

Bhanu,
As I said in my previous post, it depends on why you are doing DBC. If it is merely to get JTest to stop pointing out errors, what you are doing is enough. If you are really creating useful contracts, you will want to be more specific.

[Bhanu Vijaya]

Ahem ...
Now i have a million dollar question ! Now i find Jtest useful mainly for unit tesing.Its very good with all checks for universal coding standards!But Unit testing is taking time ,its not giving value add thru DBC,it takes a while to do unit testing for each file and it cant test Jsps too.So i feel Jtest is not a one stop shop for our testing needs as yet.
So what do we need to do if we want to implement unit testing at developers level. Jtest to be used only for coding standards? And shud we use Junit for Unit testing?
Thanks,
Bhanu

[Bhanu Vijaya]

Oops ! I am sorry ..i have to correct myself ! I meant " Jtest is mainly useful for Coding standards check and not that much useful for Unit testing and Code generation".
Thanks.

[Jeanne Boyarsky]

Bhanu,
I agree with your last statement. I think JTest is somewhat useful for unit testing (because it throws unexpected/null values at your code and tries to make it crash.) As long as you are careful that it doesn't replace developer written unit tests (which actually test logic), you will be fine.