From: Mark S. <mar...@ho...> - 2008-10-14 07:02:42
|
Hello JUnit developer team, I have a question, or rather a request: could you make the constructor (and possibly the fields) of org.junit.runner.Description "protected" instead of "private". In this way it is impossible to normally subclass Description with a custom implementation. Why would you like to subclass Description? Well, the latest implementation of Description has a rather difficult hashCode implementation, namely: hashCode = getDisplayName().hashCode(). This poses a problem (or not, but in my case it does) when you create multiple instances of the Description class with the same name. Hopefully you are willing to incorporate this minor modification, it would surely make my life easier. Big thanks, Mark Stobbe _________________________________________________________________ De mooiste afbeeldingen van Angelina Jolie vind je met Live Search http://search.live.com/images/results.aspx?q=angelina%20jolie&FORM=MIINTM |
From: David S. <da...@sa...> - 2008-10-14 13:01:13
|
Mark, I'd like to understand a little better what you're doing. Are you fine-tuning the performance of a HashMap with Descriptions as keys? David Saff On Tue, Oct 14, 2008 at 3:02 AM, Mark Stobbe <mar...@ho...> wrote: > Hello JUnit developer team, > > I have a question, or rather a request: could you make the constructor (and > possibly the fields) of org.junit.runner.Description "protected" instead of > "private". In this way it is impossible to normally subclass Description > with a custom implementation. > > Why would you like to subclass Description? Well, the latest implementation > of Description has a rather difficult hashCode implementation, namely: > hashCode = getDisplayName().hashCode(). This poses a problem (or not, but in > my case it does) when you create multiple instances of the Description class > with the same name. > > Hopefully you are willing to incorporate this minor modification, it would > surely make my life easier. > > Big thanks, > Mark Stobbe > ________________________________ > Plan je evenement, nodig mensen uit en deel je foto's met Windows Live > Events > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Junit-devel mailing list > Jun...@li... > https://lists.sourceforge.net/lists/listinfo/junit-devel > > |
From: Mark S. <mar...@ho...> - 2008-10-14 18:04:55
|
David, I'm trying to implement different testing strategies using JUnit. So basically, I implemented my own Runner which collects custom annotations similar to the suite runner. Next I use this information to prioritize/group/etc tests in different ways. This allows me to still use the Eclipse plugin, while having my own JUnit extension. However, the problem I'm running into at the moment is that whenever I have two descriptions with the same display name, then they have the same hashcode. If you take things like "groups", then these descriptions do differ in my case because they are in different groups. One solution would be to prefix the description with the group name, but i would rather like to extend the description class and use the parent/child relations to model groups. So what's the problem? Well, if two descriptions have the same hashcode, then it becomes impossible for Eclipse to correctly show the running/finished/failed tests, because notification for description 1 and 2 are done on the same hashcode. I hope that explains the problem. My question is rather simple. Is it an option for the JUnit development team to make the Description constructor protected in their next release (or even better: nightly build). Thanks in advance, Mark > Date: Tue, 14 Oct 2008 09:00:57 -0400> From: da...@sa...> To: mar...@ho...> Subject: Re: [Junit-devel] Extending the Description class> CC: jun...@li...> > Mark,> > I'd like to understand a little better what you're doing. Are you> fine-tuning the performance of a HashMap with Descriptions as keys?> > David Saff> > On Tue, Oct 14, 2008 at 3:02 AM, Mark Stobbe <mar...@ho...> wrote:> > Hello JUnit developer team,> >> > I have a question, or rather a request: could you make the constructor (and> > possibly the fields) of org.junit.runner.Description "protected" instead of> > "private". In this way it is impossible to normally subclass Description> > with a custom implementation.> >> > Why would you like to subclass Description? Well, the latest implementation> > of Description has a rather difficult hashCode implementation, namely:> > hashCode = getDisplayName().hashCode(). This poses a problem (or not, but in> > my case it does) when you create multiple instances of the Description class> > with the same name.> >> > Hopefully you are willing to incorporate this minor modification, it would> > surely make my life easier.> >> > Big thanks,> > Mark Stobbe> > ________________________________> > Plan je evenement, nodig mensen uit en deel je foto's met Windows Live> > Events> > -------------------------------------------------------------------------> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge> > Build the coolest Linux based applications with Moblin SDK & win great> > prizes> > Grand prize is a trip for two to an Open Source event anywhere in the world> > http://moblin-contest.org/redirect.php?banner_id=100&url=/> > _______________________________________________> > Junit-devel mailing list> > Jun...@li...> > https://lists.sourceforge.net/lists/listinfo/junit-devel> >> > _________________________________________________________________ Uniek: Onbeperkt chatten op je mobiel voor maar € 2,95 per maand! http://www.overaljevriendenbijje.nl/#superdeal |
From: David S. <da...@sa...> - 2008-12-03 15:03:21
|
[Adding junit-devel back in, whom I dropped off a while back] Ah, yes. You may be glad or frustrated to know that Erich and I had a discussion about this years ago, and decided that it would be quite some time before it tripped anyone up. Welcome to the end of "quite some time". :-) I'd rather not make Description non-final. It's kind of the String of JUnit--if people could suddenly, for example, create a subclass of Description with a faulty equals() implementation, all hell would break loose. Instead, I think that an optional "distinguisher" string makes sense--Eclipse could display this or not, or make it optional, but it would be used for hashCodes and comparisons. If this makes sense for you, could you please raise an issue at SourceForge? Thanks, David On Mon, Nov 24, 2008 at 4:02 PM, Mark Stobbe <mar...@ho...> wrote: > David, > > Thanks for answering so quickly. I was explaining what I wanted to achieve > but didn't > mention the problem explicitly. It is indeed the hashcode which poses a > problem. As the > Description implementation uses only the name to generate an hashcode. In > other words, > when Eclipse creates the test/suite-tree it uses these hashcodes to lookup > the item > currently running. > > So assume i have test: "TestA" and "TestB", and both are in a different > group: > > group1 > - TestA > group2 > - TestB > > Then both hashcodes are different, so when TestA is started Eclipse will > display this > correctly by changing the icon. Now, assume the same configuration only this > time > TestB is also part of group1, i.e.: > > group1 > - TestA > - TestB > group2 > - TestB > > Everything is fine when I TestA starts, but when TestB starts it shows the > TestB in group2 > as running, while it is actually the TestB in group1 which is running. So > the problem is, they > have the same hashcode. I see many solutions to this problem (at least for > me it is), but > I figured letting people subclass the Description class is the easiest to > implement and pretty > generic solution. > > However, other solutions include: > > - changing the requirements for a custom runner to allow Describeable > interface implementation > (not only Description) > - improving the hashcode by including parent hashcodes > - separating display name from actual name (i.e. name used by the hashcode) > > I hope that clears things, > Mark. > > > >> Date: Mon, 24 Nov 2008 13:54:42 -0500 >> From: da...@sa... >> To: mar...@ho... >> Subject: Re: [Junit-devel] Extending the Description class >> >> Mark, >> >> Is the subclass in order to give the Description a different name? As >> it stands, you can cheat (a little) by using >> Description.createSuiteDescription("Any name you want"); Earlier, >> though, you mentioned hashCode, so I'm thinking that what you actually >> want is two tests that are recognized as different, but whose >> Descriptions have the same name. >> >> Can you elaborate a little, so I make sure we're fixing the right >> problem? Thanks, >> >> David Saff >> >> On Mon, Nov 24, 2008 at 12:31 PM, Mark Stobbe <mar...@ho...> >> wrote: >> > David, >> > >> > That's quite ok. The project as it is now is useable, its just that we >> > would >> > like to >> > customize the description tree shown in Eclipse. At the moment we group >> > all >> > tests >> > into one suite (group) and each test in this group gets the name + a >> > numeric >> > id. >> > >> > Disadvantage of this method is that we loose the reference to the >> > correct >> > method. >> > Plus it might become weird when you have like "testMethod 23" in a group >> > while all >> > other 22 "testMethod"s are in different groups. Anyway, we will probably >> > survive this, >> > its just that it would be very nice to be able to subclass the >> > Description >> > class. >> > >> > At the moment its constructor is private, so it doesn't allow >> > inheritance. >> > I think thats >> > the only thing that really needs to change. Either that or change the >> > signature of the >> > Runner (from the top of my head), to expect a Descriptable instead of an >> > Description. >> > >> > Mark >> > >> > >> > >> >> Date: Mon, 24 Nov 2008 11:34:12 -0500 >> >> From: da...@sa... >> >> To: mar...@ho... >> >> Subject: Re: [Junit-devel] Extending the Description class >> >> >> >> Mark, >> >> >> >> I'm sorry I dropped off the grid on this conversation. I definitely >> >> want to help your project succeed. Where do things stand now, more >> >> than a month later? Thanks, >> >> >> >> David Saff >> >> >> >> 2008/10/14 Mark Stobbe <mar...@ho...>: >> >> > David, >> >> > >> >> > I'm trying to implement different testing strategies using JUnit. So >> >> > basically, I implemented my own Runner which collects custom >> >> > annotations >> >> > similar to the suite runner. Next I use this information to >> >> > prioritize/group/etc tests in different ways. This allows me to still >> >> > use >> >> > the Eclipse plugin, while having my own JUnit extension. >> >> > >> >> > However, the problem I'm running into at the moment is that whenever >> >> > I >> >> > have >> >> > two descriptions with the same display name, then they have the same >> >> > hashcode. If you take things like "groups", then these descriptions >> >> > do >> >> > differ in my case because they are in different groups. One solution >> >> > would >> >> > be to prefix the description with the group name, but i would rather >> >> > like to >> >> > extend the description class and use the parent/child relations to >> >> > model >> >> > groups. >> >> > >> >> > So what's the problem? Well, if two descriptions have the same >> >> > hashcode, >> >> > then it becomes impossible for Eclipse to correctly show the >> >> > running/finished/failed tests, because notification for description 1 >> >> > and 2 >> >> > are done on the same hashcode. >> >> > >> >> > I hope that explains the problem. My question is rather simple. Is it >> >> > an >> >> > option for the JUnit development team to make the Description >> >> > constructor >> >> > protected in their next release (or even better: nightly build). >> >> > >> >> > Thanks in advance, >> >> > Mark >> >> > >> >> > >> >> > ________________________________ >> >> >> Date: Tue, 14 Oct 2008 09:00:57 -0400 >> >> >> From: da...@sa... >> >> >> To: mar...@ho... >> >> >> Subject: Re: [Junit-devel] Extending the Description class >> >> >> CC: jun...@li... >> >> >> >> >> >> Mark, >> >> >> >> >> >> I'd like to understand a little better what you're doing. Are you >> >> >> fine-tuning the performance of a HashMap with Descriptions as keys? >> >> >> >> >> >> David Saff >> >> >> >> >> >> On Tue, Oct 14, 2008 at 3:02 AM, Mark Stobbe >> >> >> <mar...@ho...> >> >> >> wrote: >> >> >> > Hello JUnit developer team, >> >> >> > >> >> >> > I have a question, or rather a request: could you make the >> >> >> > constructor >> >> >> > (and >> >> >> > possibly the fields) of org.junit.runner.Description "protected" >> >> >> > instead >> >> >> > of >> >> >> > "private". In this way it is impossible to normally subclass >> >> >> > Description >> >> >> > with a custom implementation. >> >> >> > >> >> >> > Why would you like to subclass Description? Well, the latest >> >> >> > implementation >> >> >> > of Description has a rather difficult hashCode implementation, >> >> >> > namely: >> >> >> > hashCode = getDisplayName().hashCode(). This poses a problem (or >> >> >> > not, >> >> >> > but in >> >> >> > my case it does) when you create multiple instances of the >> >> >> > Description >> >> >> > class >> >> >> > with the same name. >> >> >> > >> >> >> > Hopefully you are willing to incorporate this minor modification, >> >> >> > it >> >> >> > would >> >> >> > surely make my life easier. >> >> >> > >> >> >> > Big thanks, >> >> >> > Mark Stobbe >> >> >> > ________________________________ >> >> >> > Plan je evenement, nodig mensen uit en deel je foto's met Windows >> >> >> > Live >> >> >> > Events >> >> >> > >> >> >> > >> >> >> > >> >> >> > ------------------------------------------------------------------------- >> >> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's >> >> >> > challenge >> >> >> > Build the coolest Linux based applications with Moblin SDK & win >> >> >> > great >> >> >> > prizes >> >> >> > Grand prize is a trip for two to an Open Source event anywhere in >> >> >> > the >> >> >> > world >> >> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> >> > _______________________________________________ >> >> >> > Junit-devel mailing list >> >> >> > Jun...@li... >> >> >> > https://lists.sourceforge.net/lists/listinfo/junit-devel >> >> >> > >> >> >> > >> >> > >> >> > >> >> > ________________________________ >> >> > Het beste van Windows, nu ook online. Deel jouw wereld met Windows >> >> > Live. >> >> > Download nu. >> >> > >> >> > >> >> > ------------------------------------------------------------------------- >> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's >> >> > challenge >> >> > Build the coolest Linux based applications with Moblin SDK & win >> >> > great >> >> > prizes >> >> > Grand prize is a trip for two to an Open Source event anywhere in the >> >> > world >> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> > _______________________________________________ >> >> > Junit-devel mailing list >> >> > Jun...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/junit-devel >> >> > >> >> > >> > >> > >> > ________________________________ >> > Plan je evenement, nodig mensen uit en deel je foto's met Windows Live >> > Events > > > ________________________________ > Chat met al je vrienden. Nodig ze nu uit voor Messenger! |