2:55 p.m.
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
3:16 p.m.
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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5 a.m.
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.
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.
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.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
5:40 a.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberry(a)redhat.com
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
6143
days inactive
6144
days old
jbosscache-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Brian Stansberry -
Galder Zamarreno -
Manik Surtani