Thread: [Junitdoclet-users] exception handling patch
Brought to you by:
sgemkow
From: Nicola F. <nic...@va...> - 2003-04-05 18:19:43
Attachments:
JUnitDoclet_exeception_handling.patch
|
hello JUnitDoclet-users, lovers & developers! I hacked around a bit on JUnitDoclet and added a feature I really missed: If a tested method throws an exception, tests should take advantage of this. I've seen this being done with JuB (http://jub.sourceforge.net/) and thought it was a really nice idea. Consider the following method: public void setPriceCode(int i) throws RuntimeException { if(i != CHILDRENS || i != REGULAR || i != NEW_RELEASE){ throw new RuntimeException("illegal price code!"); } else { priceCode = i; } } This patch makes JUnitDoclet generate automatically a test-method body like this: public void testGetTitle() throws Exception { // JUnitDoclet begin method getTitle //insert code testing basic functionality try { movie.getTitle(null); } catch (Throwable e) { fail("Failed with:" + e); } //insert code triggering RuntimeException try { movie.getTitle(null); fail("Should raise RuntimeException"); } catch (RuntimeException e) { } catch (Throwable e) { fail("Failed with:" + e); } //insert code triggering Exception try { movie.getTitle(null); fail("Should raise Exception"); } catch (Exception e) { } catch (Throwable e) { fail("Failed with:" + e); } // JUnitDoclet end method getTitle } Of course, you have to add some bits & pieces to make the tests compilable, but the main idea is here... BTW, the whole thing works very well with multiple exceptions, too. To apply the patch, get the source distribution, unzip the src.zip in it and then execute this: patch -p1 -u < JUnitDoclet_exeception_handling.patch hope anyone will find this useful... regards nicola |
From: Nicola F. <nic...@va...> - 2003-04-06 07:22:56
Attachments:
JUnitDoclet_exeception_handling.patch
|
hello first of all, the patch sent out yesterday had a pretty dumb bug, which this patch solves. so if you want to play with it, be sure to apply this one (altough the older won't rm -rf your machine). and for the attentive people out there: yes, the two code pieces in my last mail did not fit together really well... :) btw: is anyone interested in writing a real Eclipse plugin for JUnitDoclet? While I myself don't have enough time to do that I'd be a happy user of it... :) regards nicola |
From: <ste...@ob...> - 2003-04-06 16:21:18
|
Hi Nicola, > first of all, the patch sent out yesterday had a pretty dumb bug, which > this patch solves. Relax. Think. Did you check your patch this time? Really? The update frequency of JUnitDoclet is not as high as in other projects, but there is good news in that: Don't touch a running system (if it's not nessecary). Well, actually some users sent me suggestions to improve JUnitDoclet. That is highly welcome and their contributions will be in the next release. I love that. What I don't enjoy in that much detail is a stream of untested patches, that make our software appear unstable. To be forced to react on this issue takes away time from developing the tool. (I admit, in the last few months I've been busy with other topics, but now some of my time is for JUnitDoclet again. So the statement is true.) Before we release a new version we run a lot of tests. (Testing before the user does, isn't JUnit all about that?) There is always a chance for one more bug, but we do a lot to make it a small chance. Please, at least try the same with anything you release. With respect to the goal you try to achive: Is testing an exception really worth complicating any tool? How often is it used in good programs? In my opinion exceptions should be used only in exceptional cases. So there is very little of them. Right? Don't test RuntimeExceptions if you don't throw them (and you should't throw them) ! Just one example: There are so many ways you can run out of memory... you test for that with other tools, better suited for that purpose. One major design goal of JUnitDoclet is: predictable behaviour This means: It is better to do nothing and point to the missing part, than doing something which is sometimes wrong. IMHO there is not only "not enough testing" there is also a "to much test code" when the real tests get hidden behind a cloud of meaningless, generated code. Actually that is what some of the other test geneators do: They claim to think on behalf of the developer and produce nice, compilable clouds. JUnitDoclet meight generate some kind of tests for non RuntimeExceptions in the future but not now. As our software develops in iteratations, there are features that are much more important. Those will even serve as a better foundation for testing exceptions by preventing clouding the tests. I hope you will agree when the next release is out, even if exceptions are not adressed. This email is not ment as an offense. You like our tool, you use it, you spent time to add something which seems usefull to you. You even shared your idea. That is Open Source. Thank you. All I ask is a little bit more testing before someone sends out a message like you did. If someone has an idea to improve our tool, please send an email to jun...@ob.... We'll be more than happy to discuss that. And if it seems usefull to us too, it may even make it into the next release (as do other user suggestions like configurations for indent levels and accessor prefixes). Keep on testing. Regards, Steffen Gemkow -- ObjectFab GmbH ste...@ob... |
From: Nicola F. <nic...@va...> - 2003-04-06 17:51:31
|
hello steffen On Sun, 2003-04-06 at 18:25, ste...@ob... wrote: [..snipped dismissive rant..] > The update frequency of JUnitDoclet is not as high as > in other projects, but there is good news in that: > > Don't touch a running system (if it's not nessecary). I deemed it necessary. And luckily I have other things to do than writing novels - because then I'd refactored JUnitDoclet so nobody would have recognized it again. No seriously, JUnitDoclet does a wonderful job, but needs change quite badly IMO. Important classes are very big (talking about DefaultTestingStrategy), and I have not encountered one exception in the whole project - everything is done with return values, even errors are reported back this way. clearly not that elegant, but works admittedly. > What I don't enjoy in that much detail is a stream of > untested patches, that make our software appear > unstable. To be forced to react on this issue takes Are you afraid of people contributing code and the fact that you cannot control what exactly floats around (speaking of patches)? I understand up to a certain degree. But it is still your group releasing official releases - so nobody (mentally sane) will complain about a non-official patch not working correctly. > away time from developing the tool. (I admit, in the > last few months I've been busy with other topics, but > now some of my time is for JUnitDoclet again. So > the statement is true.) Very glad to hear that. > Before we release a new version we run a lot of tests. > (Testing before the user does, isn't JUnit all about that?) 100% ack. and why do 8 of your 105 tests fail constantly, even without having touched the code? :) btw, with my patch the exact same 8 tests still fail. is this success? ;) > With respect to the goal you try to achive: > Is testing an exception really worth complicating any > tool? How often is it used in good programs? In my Sorry, no offence, but exceptions are an integral part of Java and if you don't think so, I have no problem with that either. But please let the other 95% Java programmers use exceptions, ok? :) > opinion exceptions should be used only in exceptional > cases. So there is very little of them. Right? Exactly. And what do you do, if (for example) somebody tries to set a negative price on a product? Business as usual? I'd throw them a IllegalPriceException right in the face! Generally speaking: Programming C in Java is certainly possible, but it's like speaking English with French accent. Works, but is suboptimal. > Don't test RuntimeExceptions if you don't throw them > (and you should't throw them) ! I have to admit that my example was kind of confusing. The patch only generates additional code if there _are_ exceptions declared to be thrown, and only then tests only those. You can check out the exact behavior for yourself, if you are interested. > IMHO there is not only "not enough testing" there is > also a "to much test code" when the real tests get > hidden behind a cloud of meaningless, generated code. 100% ack again. > Actually that is what some of the other test geneators > do: They claim to think on behalf of the developer and > produce nice, compilable clouds. mine are not even compilable, sniff. :) well, I put my thinking into code. And if someone does not like my thinking, he's better without my patch. It was never intended being different. > JUnitDoclet meight generate some kind of tests for non > RuntimeExceptions in the future but not now. As our > software develops in iteratations, there are features > that are much more important. Those will even serve as > a better foundation for testing exceptions by preventing > clouding the tests. I hope you will agree when the next > release is out, even if exceptions are not adressed. I will certainly take a look at the new release. > This email is not ment as an offense. You like our tool, > you use it, you spent time to add something which > seems usefull to you. You even shared your idea. > That is Open Source. Thank you. It is interesting how your email has changed attitude in itself (when comparing the first dismissive lines you wrote with this quite nice paragraph at the end). And yes, that's the way open source works. You don't have to like my patches (what the hell reminds me now of Linus? :), but I don't have hold back my patches either. After all, open source is about freedom, right? > All I ask is a little bit more testing before someone sends > out a message like you did. If someone has an idea to > improve our tool, please send an email to > jun...@ob.... We'll be more than happy to That maybe have been the way it worked until now. You have to accept that there are also creative people out there using the freedom you gave to them - they build their dreams with their own hands and don't have to beg. I certainly won't send bother you with an email if I see that the change is no more than 2-3 hours worth of programming and so can be done by me... > discuss that. And if it seems usefull to us too, it may > even make it into the next release (as do other user > suggestions like configurations for indent levels and > accessor prefixes). I assume I stepped on your toes - I am sorry for that. I am however not sorry for my belief in open, direct & fast communication - so I still think this patch got out the right time. If you don't like my patch being published on sf.net, then drop me a line and delete it, so I can put it on my website. One question: why did you chose the LGPL as license and not the GPL? Using GPL software for commercial software engineering is perfectly legal - or is there another reason? regards nicola |
From: <ste...@ob...> - 2003-04-06 20:05:56
|
Hi Nicola, > > The update frequency of JUnitDoclet is not as high as > > in other projects, but there is good news in that: > > > > Don't touch a running system (if it's not nessecary). > > I deemed it necessary. And luckily I have other things to do than > writing novels - ... ;-) > No seriously, JUnitDoclet does a wonderful job, but needs change quite > badly IMO. Important classes are very big (talking about > DefaultTestingStrategy), and I have not encountered one exception in the > whole project - everything is done with return values, even errors are > reported back this way. clearly not that elegant, but works admittedly. There are things that need refactoring. True. > > What I don't enjoy in that much detail is a stream of > > untested patches, that make our software appear > > unstable. To be forced to react on this issue takes > > Are you afraid of people contributing code and the fact that you cannot > control what exactly floats around (speaking of patches)? I understand > up to a certain degree. I'm glad you wrote that. > > Before we release a new version we run a lot of tests. > > (Testing before the user does, isn't JUnit all about that?) > > 100% ack. and why do 8 of your 105 tests fail constantly, even without > having touched the code? :) The tests passed when we released. And they passed a minute ago. Maybe you've changed something else? > btw, with my patch the exact same 8 tests still fail. is this success? > ;) Not exactly. > > With respect to the goal you try to achive: > > Is testing an exception really worth complicating any > > tool? How often is it used in good programs? In my > > Sorry, no offence, but exceptions are an integral part of Java and if > you don't think so, I have no problem with that either. But please let > the other 95% Java programmers use exceptions, ok? :) Sure you can use them. > > opinion exceptions should be used only in exceptional > > cases. So there is very little of them. Right? > > Exactly. And what do you do, if (for example) somebody tries to set a > negative price on a product? Business as usual? I'd throw them a > IllegalPriceException right in the face! Well, I don't. But I would let the user know too. > Generally speaking: Programming C in Java is certainly possible, but > it's like speaking English with French accent. Works, but is suboptimal. I don't have to use something just because it's there. I use it, when I see fit. Ever thought about encapsulation? What do you think of a program spreading IllegalPriceExceptions and the knowledge to handle them all over the application? (I'd like to suggest a book: "The Pragmatic Programmer" or "Der Pragmatische Programmierer" if you prefer a german translation.) > You can check out the exact behavior for yourself, if you are > interested. I will look at it later, but I will. > > This email is not ment as an offense. You like our tool, > > you use it, you spent time to add something which > > seems usefull to you. You even shared your idea. > > That is Open Source. Thank you. > > It is interesting how your email has changed attitude in itself (when > comparing the first dismissive lines you wrote with this quite nice > paragraph at the end). I didn't change it, while you where reading. ;-) > And yes, that's the way open source works. You don't have to > like my patches (what the hell reminds me now of Linus? :), but > I don't have hold back my patches either. After all, open source is > about freedom, right? Freedom is important. Open Source is about cooperation on behalf of usefull software. > > All I ask is a little bit more testing before someone sends > > out a message like you did. If someone has an idea to > > improve our tool, please send an email to > > jun...@ob.... We'll be more than happy to > > That maybe have been the way it worked until now. Your statement does not sound like freedom to me. > You have to accept that > there are also creative people out there using the freedom you gave to them > - they build their dreams with their own hands and don't have to beg. Begging? Ever heard of feature requests? > I certainly won't send bother you with an email if I see that the change > is no more than 2-3 hours worth of programming and so can be done by me... That's ok. You've got the source for that. Releasing buggy "patches" may be freedom to you, but is irritating to other users of JUnitDoclet (since they meight have difficulties to differenciate between the source of a patch. I wouldn't even bothered, if your first patch would have been working. > > discuss that. And if it seems usefull to us too, it may > > even make it into the next release (as do other user > > suggestions like configurations for indent levels and > > accessor prefixes). > > I assume I stepped on your toes - I am sorry for that. It's not my ego, that was hurt. If only one other user applied your patch, he/she meight think different about our tool now. That is, what I don't like. > I am however not > sorry for my belief in open, direct & fast communication - so I still > think this patch got out the right time. Well, you meight try to communicate before you release a patch. At least try. That does not limit your freedom, right? I guess my responses have been open, direct & fast enough. > If you don't like my patch being published on sf.net, then drop me a > line and delete it, so I can put it on my website. I've made the patches available to a smaller group already. If you let me know your website, I meight have a look at it. > One question: why did you chose the LGPL as license and not the GPL? > Using GPL software for commercial software engineering is perfectly > legal - or is there another reason? <quote source="http://www.gnu.org/licenses/why-not-lgpl.html"> The GNU Project has two principal licenses to use for libraries. One is the GNU Library GPL; the other is the ordinary GNU GPL. The choice of license makes a big difference: using the Library GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs. </quote> Regards, Steffen Gemkow -- ObjectFab GmbH ste...@ob... |
From: Nicola F. <nic...@va...> - 2003-04-06 20:44:02
|
hi steffen On Sun, 2003-04-06 at 22:10, ste...@ob... wrote: > The tests passed when we released. And they passed a minute > ago. Maybe you've changed something else? Hm, gotta fix that the next time I play around with it. > Ever thought about encapsulation? What do you think > of a program spreading IllegalPriceExceptions and the > knowledge to handle them all over the application? > (I'd like to suggest a book: "The Pragmatic Programmer" > or "Der Pragmatische Programmierer" if you prefer a > german translation.) I fully agree that such an IllegalPriceException should only be thrown to an object directly accessing the setPrice() method and be caught at the caller (the caller might decide to throw another, more general exception [generally] then to _his_ caller if it was his caller's fault). And yes, I am fully capable of reading English books. thank you. :) And besides, I also fully agree that wizards are evil (at least most of them). Isn't JUnitDoclet a wizard? Hm. > > That maybe have been the way it worked until now. > > Your statement does not sound like freedom to me. Might be new for you: Freedom != Holidays > Begging? Ever heard of feature requests? Surely, but I have the feeling that even tough you honor a request, it's still the team leader that decides which suggestions are finally implemented (which is ok, besides). But for me writing what I need _is_ an option, so I use it when I have the freedom (and time :). Otherwise, I gladfully write some feature requests... :) > Releasing buggy "patches" may be freedom to you, but is > irritating to other users of JUnitDoclet (since they meight > have difficulties to differenciate between the source of a > patch. I wouldn't even bothered, if your first patch would > have been working. Sorry for that. To err is human. > It's not my ego, that was hurt. If only one other user applied > your patch, he/she meight think different about our tool now. > That is, what I don't like. Do you know the Compaq FAQ entry explaining "where the Any-key" is? Some people never get it. Some people just shouldn't program (maybe me included - but who else would then get the work done? :). > Well, you meight try to communicate before you release > a patch. At least try. That does not limit your freedom, right? I will send my (stable) patches meant as a suggestion for a next release first to you, promised. :) > <quote source="http://www.gnu.org/licenses/why-not-lgpl.html"> > The GNU Project has two principal licenses to use for libraries. One > is the GNU Library GPL; the other is the ordinary GNU GPL. The > choice of license makes a big difference: using the Library GPL > permits use of the library in proprietary programs; using the > ordinary GPL for a library makes it available only for free programs. </quote> Thank you for this hard-to-find link! Was the reason to stick to this license driven by the thought that someone would want to _include_ JUnitDoclet into some proprietary products? Or was it merely to allow people to use (the free) JUnitDoclet to generate tests for their (unfree) proprietary program? btw, you're welcome for the hint with the sf.net patches. I only find it sad that the whole menu entry has disappeared since you removed my patch from public! :) regards nicola ps: your nice xml style for the quote brings my to another suggestion: why not use XML as configuration format for JUnitDoclet? Fact is, properties-files are ugly and some buzzwords like XML and maybe XPath (or what is it called today) would surely frehen intereset in JUnitDoclet, don't you think? |
From: <ste...@ob...> - 2003-04-06 22:05:39
|
Nicola, > And yes, I am fully capable of reading English books. thank you. :) This was not what I ment. ;-) Maybe you want to read the book anyway. > And > besides, I also fully agree that wizards are evil (at least most of > them). Isn't JUnitDoclet a wizard? Hm. See FAQ. > > > That maybe have been the way it worked until now. > > > > Your statement does not sound like freedom to me. > > Might be new for you: Freedom != Holidays Freedom is the right to do whatever one likes as long as it does not interfere with the freedom of other people. I like the sound of that. > > Begging? Ever heard of feature requests? > > Surely, but I have the feeling that even tough you honor a request, it's > still the team leader that decides which suggestions are finally > implemented (which is ok, besides). So why din't you even try to communicate with the team leader? Well, forget it. > But for me writing what I need _is_ an option, so I use it when I have > the freedom (and time :). Otherwise, I gladfully write some feature > requests... :) That's what the source code is for. Modify and use it. If you like it, make it a feature request. So it may be in the next release and you don't have to worry about maintaining it. > > It's not my ego, that was hurt. If only one other user applied > > your patch, he/she meight think different about our tool now. > > That is, what I don't like. > > Do you know the Compaq FAQ entry explaining "where the Any-key" is? Some > people never get it. Some people just shouldn't program (maybe me > included - but who else would then get the work done? :). Well, who shows attitude now? > > Well, you meight try to communicate before you release > > a patch. At least try. That does not limit your freedom, right? > > I will send my (stable) patches meant as a suggestion for a next release > first to you, promised. :) Ok. > > <quote source="http://www.gnu.org/licenses/why-not-lgpl.html"> > > The GNU Project has two principal licenses to use for libraries. One > > is the GNU Library GPL; the other is the ordinary GNU GPL. The > > choice of license makes a big difference: using the Library GPL > > permits use of the library in proprietary programs; using the > > ordinary GPL for a library makes it available only for free programs. </quote> > > Thank you for this hard-to-find link! Was the reason to stick to this > license driven by the thought that someone would want to _include_ > JUnitDoclet into some proprietary products? Or was it merely to allow > people to use (the free) JUnitDoclet to generate tests for their > (unfree) proprietary program? Maybe a bit of both and some other reasons? > btw, you're welcome for the hint with the sf.net patches. I only find it > sad that the whole menu entry has disappeared since you removed my patch > from public! :) You helped me to decide, we would rather make a minor release then provide a patch. Whether or not the patches are public is just an option in the admin pages. Since we won't use it, I turned it off. Your patch is not gone, but provided to the team only. So there won't be a buggy patch on our project again. As you've sad: There are better things to do, than writing novels. > ps: your nice xml style for the quote brings my to another suggestion: Yes, I have seen what projects you are involved with. Properties may not be the coolest thing, but they are installed where Java is installed. When they go XML, JUnitDoclet will. Regards, Steffen Gemkow -- ObjectFab GmbH ste...@ob... |
From: Nicola F. <nic...@va...> - 2003-04-07 06:22:47
|
hi steffen On Mon, 2003-04-07 at 00:09, ste...@ob... wrote: > Well, who shows attitude now? At least I can make fun of me. I am certainly no code-god. > > Thank you for this hard-to-find link! Was the reason to stick to this > > license driven by the thought that someone would want to _include_ > > JUnitDoclet into some proprietary products? Or was it merely to allow > > people to use (the free) JUnitDoclet to generate tests for their > > (unfree) proprietary program? > > Maybe a bit of both and some other reasons? I don't know how many lawyers you put on this issue, but it seems to me that GPL allows use of GPL'ed programs for developing commercial/propretiary software (although IANAL). > Properties may not be the coolest thing, but they > are installed where Java is installed. When they > go XML, JUnitDoclet will. ok, dependance of XML parsers is a reason. after nobody uses jdk 1.3 anyomore, there should be no more problems with that, since after jdk 1.4 there is JAXP and a default XML parser AFAIK. ok, steffen, it was nice talking to you this weekend, but now I gotta go back and use my brand-new and enhanced JUnitDoclet to write some (almost) real software... :) If anynone is still in my (bugridden? :) patch for JUnitDoclet, they can visit: http://variant.ch/phpwiki/JUnitDocletPatches and get it there. regards nicola |