You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by ran tene <ra...@hotmail.com> on 2001/10/05 18:48:20 UTC
contract and unit tests
there is a wide gap between the documented english writen contract of the ComponentManager and ComponentSelctor and its implementation - the implementation is much wider.
the writen contract is only one possible way of using the classes.
when i wrote the unit tests i faced this problem.
which contract should i check?
1-the english one.
2-the code.
option 1 makes the unit test more helpfull for peaople who wants to learn how the code was
meant to be used. -part of the documentation.
what is the real contract of the classes?
this time i checked the code contract- option 2 ,but im not sure ...
...
ran
Re: contract and unit tests
Posted by Berin Loritsch <bl...@apache.org>.
> ran tene wrote:
>
> there is a wide gap between the documented english writen contract of the ComponentManager and ComponentSelctor and its
> implementation - the implementation is much wider.
> the writen contract is only one possible way of using the classes.
> when i wrote the unit tests i faced this problem.
> which contract should i check?
> 1-the english one.
> 2-the code.
> option 1 makes the unit test more helpfull for peaople who wants to learn how the code was
> meant to be used. -part of the documentation.
> what is the real contract of the classes?
> this time i checked the code contract- option 2 ,but im not sure ...
The documented contract is what is necessary. If the implementation is too broad,
then we may need to narrow it.
>
> ...
> ran
>
>
> Name: DefaultComponentSelectorTestCase.java
> DefaultComponentSelectorTestCase.java Type: Java Class (java/*)
> Encoding: quoted-printable
>
> Name: DefaultComponentManagerTestCase.java
> DefaultComponentManagerTestCase.java Type: Java Class (java/*)
> Encoding: quoted-printable
>
> ---------------------------------------------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: contract and unit tests
Posted by ran tene <ra...@hotmail.com>.
ok, I agree.
I will write new tests
ran
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Monday, October 08, 2001 3:23 PM
Subject: Re: contract and unit tests
> ran tene wrote:
> >
> > i just meant that i can check the code in one fo the ways it was meant
to
> > be/is used
> > for example
> > try
> > {
> > MyComponent log;
> > myComponent = (MyComponent) manager.lookup(MyComponent.ROLE);
> > }
> > catch (...)
> > {
> > ...
> > }
> > or in any other way that it can be used
> > for example:
> > try
> > {
> > MyComponent log;
> > myComponent = (MyComponent) manager.lookup("some-string");
> > }
> > catch (...)
> > {
> > ...
> > }
> > if i choose the first option then
> > 1 - people can use the test to learn how to use the class. the thoght
behind
> > the class.
> > 2 - but, changes in the class implementaiton which depend on the fact
that
> > role represent some interface or any static field will not result in a
> > failure (i know its a paranoidic thought ,but maybe thats what tests
are
> > for).
> >
> > my question is about the target of unit tests.
>
> In this case your test should match what is documented. The Component
manager
> should look up ROLEs. Technically, we could test for illegal characters
like
> the hyphen (this is for interface names), but during run time, that is not
an
> acceptable performance hit.
>
> >
> > p.s.
> > sorry for my english
> > your project is very interesting. I want to use it for some application
> > server
> > for a distributed gui.
> >
> > thanx
> > ran
> >
> > ----- Original Message -----
> > From: "Peter Donald" <do...@apache.org>
> > To: "Avalon Development" <av...@jakarta.apache.org>
> > Sent: Sunday, October 07, 2001 7:46 AM
> > Subject: Re: contract and unit tests
> >
> > > On Sat, 6 Oct 2001 02:48, ran tene wrote:
> > > > there is a wide gap between the documented english writen contract
of
> > the
> > > > ComponentManager and ComponentSelctor and its implementation - the
> > > > implementation is much wider. the writen contract is only one
possible
> > way
> > > > of using the classes. when i wrote the unit tests i faced this
problem.
> > > > which contract should i check?
> > > > 1-the english one.
> > > > 2-the code.
> > > > option 1 makes the unit test more helpfull for peaople who wants to
> > learn
> > > > how the code was meant to be used. -part of the documentation.
> > > > what is the real contract of the classes?
> > > > this time i checked the code contract- option 2 ,but im not sure ...
> > >
> > > Could you describe the differences?
> > >
> > > --
> > > Cheers,
> > >
> > > Pete
> > >
> > > When a stupid man is doing something he's ashamed of, he always
> > > declares that it is his duty.
> > > George Bernard Shaw
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: contract and unit tests
Posted by Berin Loritsch <bl...@apache.org>.
ran tene wrote:
>
> i just meant that i can check the code in one fo the ways it was meant to
> be/is used
> for example
> try
> {
> MyComponent log;
> myComponent = (MyComponent) manager.lookup(MyComponent.ROLE);
> }
> catch (...)
> {
> ...
> }
> or in any other way that it can be used
> for example:
> try
> {
> MyComponent log;
> myComponent = (MyComponent) manager.lookup("some-string");
> }
> catch (...)
> {
> ...
> }
> if i choose the first option then
> 1 - people can use the test to learn how to use the class. the thoght behind
> the class.
> 2 - but, changes in the class implementaiton which depend on the fact that
> role represent some interface or any static field will not result in a
> failure (i know its a paranoidic thought ,but maybe thats what tests are
> for).
>
> my question is about the target of unit tests.
In this case your test should match what is documented. The Component manager
should look up ROLEs. Technically, we could test for illegal characters like
the hyphen (this is for interface names), but during run time, that is not an
acceptable performance hit.
>
> p.s.
> sorry for my english
> your project is very interesting. I want to use it for some application
> server
> for a distributed gui.
>
> thanx
> ran
>
> ----- Original Message -----
> From: "Peter Donald" <do...@apache.org>
> To: "Avalon Development" <av...@jakarta.apache.org>
> Sent: Sunday, October 07, 2001 7:46 AM
> Subject: Re: contract and unit tests
>
> > On Sat, 6 Oct 2001 02:48, ran tene wrote:
> > > there is a wide gap between the documented english writen contract of
> the
> > > ComponentManager and ComponentSelctor and its implementation - the
> > > implementation is much wider. the writen contract is only one possible
> way
> > > of using the classes. when i wrote the unit tests i faced this problem.
> > > which contract should i check?
> > > 1-the english one.
> > > 2-the code.
> > > option 1 makes the unit test more helpfull for peaople who wants to
> learn
> > > how the code was meant to be used. -part of the documentation.
> > > what is the real contract of the classes?
> > > this time i checked the code contract- option 2 ,but im not sure ...
> >
> > Could you describe the differences?
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > When a stupid man is doing something he's ashamed of, he always
> > declares that it is his duty.
> > George Bernard Shaw
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: contract and unit tests
Posted by Peter Donald <do...@apache.org>.
On Sat, 6 Oct 2001 19:34, ran tene wrote:
> i just meant that i can check the code in one fo the ways it was meant to
> be/is used
> for example
> try
> {
> MyComponent log;
> myComponent = (MyComponent) manager.lookup(MyComponent.ROLE);
> }
> catch (...)
> {
> ...
> }
> or in any other way that it can be used
> for example:
> try
> {
> MyComponent log;
> myComponent = (MyComponent) manager.lookup("some-string");
> }
> catch (...)
> {
> ...
> }
> if i choose the first option then
> 1 - people can use the test to learn how to use the class. the thoght
> behind the class.
> 2 - but, changes in the class implementaiton which depend on the fact that
> role represent some interface or any static field will not result in a
> failure (i know its a paranoidic thought ,but maybe thats what tests are
> for).
Oh - okay. The first method is the preferred method while the second form was
our older style.
> my question is about the target of unit tests.
>
> p.s.
> sorry for my english your project is very interesting. I want to use it for
> some application server for a distributed gui.
Your english is fine ;)
--
Cheers,
Pete
---------------------------------------------------
For every complex problem there is a solution that
is simple, neat and wrong
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: contract and unit tests
Posted by ran tene <ra...@hotmail.com>.
i just meant that i can check the code in one fo the ways it was meant to
be/is used
for example
try
{
MyComponent log;
myComponent = (MyComponent) manager.lookup(MyComponent.ROLE);
}
catch (...)
{
...
}
or in any other way that it can be used
for example:
try
{
MyComponent log;
myComponent = (MyComponent) manager.lookup("some-string");
}
catch (...)
{
...
}
if i choose the first option then
1 - people can use the test to learn how to use the class. the thoght behind
the class.
2 - but, changes in the class implementaiton which depend on the fact that
role represent some interface or any static field will not result in a
failure (i know its a paranoidic thought ,but maybe thats what tests are
for).
my question is about the target of unit tests.
p.s.
sorry for my english
your project is very interesting. I want to use it for some application
server
for a distributed gui.
thanx
ran
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Sunday, October 07, 2001 7:46 AM
Subject: Re: contract and unit tests
> On Sat, 6 Oct 2001 02:48, ran tene wrote:
> > there is a wide gap between the documented english writen contract of
the
> > ComponentManager and ComponentSelctor and its implementation - the
> > implementation is much wider. the writen contract is only one possible
way
> > of using the classes. when i wrote the unit tests i faced this problem.
> > which contract should i check?
> > 1-the english one.
> > 2-the code.
> > option 1 makes the unit test more helpfull for peaople who wants to
learn
> > how the code was meant to be used. -part of the documentation.
> > what is the real contract of the classes?
> > this time i checked the code contract- option 2 ,but im not sure ...
>
> Could you describe the differences?
>
> --
> Cheers,
>
> Pete
>
> When a stupid man is doing something he's ashamed of, he always
> declares that it is his duty.
> George Bernard Shaw
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: contract and unit tests
Posted by Peter Donald <do...@apache.org>.
On Sat, 6 Oct 2001 02:48, ran tene wrote:
> there is a wide gap between the documented english writen contract of the
> ComponentManager and ComponentSelctor and its implementation - the
> implementation is much wider. the writen contract is only one possible way
> of using the classes. when i wrote the unit tests i faced this problem.
> which contract should i check?
> 1-the english one.
> 2-the code.
> option 1 makes the unit test more helpfull for peaople who wants to learn
> how the code was meant to be used. -part of the documentation.
> what is the real contract of the classes?
> this time i checked the code contract- option 2 ,but im not sure ...
Could you describe the differences?
--
Cheers,
Pete
When a stupid man is doing something he's ashamed of, he always
declares that it is his duty.
George Bernard Shaw
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org