[jbosscache-dev] poll: java tag for shortcut set up methods created only for UT purposes?

[Galder Zamarreno]

On 12 Jul 2007, at 12:00, Manik Surtani wrote:

> What I tend to do is to have such methods (or even class fields) as  
> package protected.  In most cases, the unit test in question shares  
> the same package name as the class being tested and would have  
> access to class internals.
>
> I don't agree with messaging and their thought that only public  
> methods should be tested - this is black box testing, and while  
> useful, is not the only form of testing that should occur IMO.  I  
> think a certain degree of internal access can be useful when, for  
> example, injecting mock objects into the class being tested to  
> analyse behaviour of how internal fields are used by the class.

Good. We're all in the same page.

>
> Regarding tagging, I agree with Brian that unless there is some  
> consolidated effort to standardise an annotation or something to  
> this effect so it doesn't appear in IDE drop downs, this is  
> relatively meaningless.  Public interfaces and helper methods on  
> implementation classes makes sense where interfaces make sense -  
> but beyond that, I just think using pretty explicit javadocs is the  
> best thing we can do here.

Ok, I'll stick to javadocs. Sounds like a good middle ground.

>
>
> On 11 Jul 2007, at 21:16, Brian Stansberry wrote:
>
>> Why do you need a tag for that, rather than Javadoc? The only  
>> advantage I could see for a tag would be if there were tool  
>> support for it so the method didn't show up in code completion or  
>> something. Doubt that's gonna happen.

It'd be "cool" though if there's support for something similar  
wouldn't it? :)

>>
>> I've certainly seen methods like you describe, and have probably  
>> written some. Seems better to avoid if possible, particularly if  
>> invoking the method screws things up if you don't understand the  
>> secrets of the class.
>>
>> Slightly off topic, but I generally prefer writing a lot of  
>> interfaces and clearly stating in both the interface javadoc and  
>> the impl class javadoc that the interface is the API (or SPI). I  
>> then feel more comfortable about adding methods to the impl class.
>>
>> Galder Zamarreno wrote:
>>> Hi,
>>> Quite often when contributing in JBoss projects, I create extra  
>>> protected methods (i.e. setters)
>>> to make my life a lot simpler when coding unit tests. People have  
>>> different opinions (such as
>>> the messaging guys who believe every single UT should be coded to  
>>> the public API), but I
>>> personally believe that you shouldn't be necessarily forced to  
>>> set up a complete environment
>>> to run a specific UT. There're a lot of situations where it makes  
>>> sense to do this, but others where
>>> not, and in the latter, having "shortcut" set up methods helps.
>>> Sometimes, this "shortcut" methods are already there but other  
>>> times are not, hence my tendency
>>> to create these protected methods.  Now, wouldn't it be nice if  
>>> there's a Java tag
>>> that could be applied to this methods to indicate that:
>>> "this method is only here to make my unit-testing-coding-life  
>>> easier and so, should only be called from
>>> unit tests, not from production code"
>>> I had a quick look around and could not find anything. Do people  
>>> agree/disagree with creating such tag?
>>> Cheers,
>>> Galder
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>>
>> -- 
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> brian.stansberry at redhat.com
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
>
>