Re: [Hibernate] questions regarding development setup

[Max R. A. <max...@jb...>]

>> You're right.  We should never have "expected failure" type tests in a
> test suite so that we
>> can get back to things we know we want to fix.  That is so crazy; what=
 =20
>> are
> we thinking here=E2=80=A6

> How
> can developer know if the codebase in svn is not broken? - only by =20
> comparing
> list of failures with list of expected failures. And you guys have to =20
> make
> this comparison every time you evaluate someone's patch...

It is not optimal, but it is quite easy to see if a method not called =20
failureExpected is failing.

We know it is not optimal, but it is better than removing those tests.

> to particular log in issue management tool... It just doesn't work in C=
I
> based environment. I see no reason of creating only testcase (w/o fix) =
=20
> since
> you have the information about the bug in jira. You defer the bugfix to
> vague future... when something changes regarding the bug on jira you =20
> have to
> update testcase... Bug should be covered with test, then fixed, then =20
> checked
> into svn... Does having failing testcases of known bugs is a reason to =
be
> proud?

Having the tests only in jira make them being deferred even longer.

> You may have process of estimation/analysis of a jira log with the =20
> output of
> failing testcase. If it's working for you - that's great. But in my =20
> opinion
> developer should have a clear understanding of stable code base which i=
s
> green color on junit progress bar. And the development should be red ->
> green -> refactor not red -> red -> refactor.

Again, we prefer to have the failureExpected then none at all.

>> And do you rather want us to remove tests for known issues ?
>
> I'd prefer refactor to separate source folder, perhaps not taking part =
in
> main build and in future not checking into svn without an actual bugfix=
 =20
> :)

If you looked at the tests you would see why they are not in seperate =20
classes/folders
would add very redundant testcode that is even worse to maintain.

Again, as Scott so correctly pointed out; it is a limitation of the =20
unittest framework
we are trying to cope with.

/max

> Thanks,
> Szczepan Faber
>
> On 6/9/06, Max Rydahl Andersen <max...@jb...> wrote:
>>
>>
>> >> The day you write a (needed and usefull!) unittest that is not =20
>> possible
>> >> in our current setup then lets talk ;)
>> >
>> > I've already created patch with couple testcases using same package
>> > layout
>> > on purpose.
>>
>> ok.
>>
>> >> No reason to change what just works.
>> >
>> > reasons: every time the developer cannot unit test non-public method=
 /
>> > class
>> > w/o public constructor. (every day :) ?)
>>
>> well, it has never been an issue since we have more than enough tests =
=20
>> that
>> does this, so again it just works.
>>
>> > Anyway I will just contribute a patch and let's see what you say...
>>
>> ok.
>>
>> > PS
>> > Whatever you say, the failing tests / unreasonable test packaging ju=
st
>> > impact the project credibility. But it's just my opinion and my
>> > collegues.
>>
>> unreasonable test packaging ? Nothing *prevents* you from using anothe=
r
>> layout - and
>> since our testsuite contains considerable more test than I've seen
>> compared to other
>> applications/frameworks it doesn't seem to be an issue in real life vs.
>> theoretical rants.
>>
>> And do you rather want us to remove tests for known issues ? That soun=
ds
>> like you want
>> us to hide the fact we know some part has a bug/issue ? how is that fo=
r
>> credibility ?
>>
>> /max
>>
>> > Thanks,
>> > Szczepan
>> >
>> >
>> > On 6/9/06, Max Rydahl Andersen <max...@jb...> wrote:
>> >>
>> >>
>> >> > b) But what's the reason of making surprising test subpackage (I'=
ve
>> >> never
>> >> > seen something like that)? You can still have =20
>> integration/acceptance
>> >> test
>> >> > cases in 'normal' package or even in different source folder.
>> >> > Unreasonable
>> >> > subpackage makes it hard to write real unit test, you cannot test=
 =20
>> non
>> >> > public methods, you cannot instantiate some classes etc. Don't yo=
u
>> >> have
>> >> a
>> >> > refactoring plan to remove test subpackage?
>> >>
>> >> No reason to change what just works.
>> >>
>> >> The day you write a (needed and usefull!) unittest that is not =20
>> possible
>> >> in our current setup then lets talk ;)
>> >>
>> >> /max
>> >>
>> >> >
>> >> > Thanks,
>> >> > Szczepan
>> >> >
>> >> >
>> >> > On 6/8/06, Max Rydahl Andersen <max...@jb...> wrote:
>> >> >>
>> >> >> > 1. Why there are about 10 failing test after getting project =20
>> from
>> >> svn?
>> >> >>
>> >> >> a) if the method ends in "FailureExpected", then it is an expect=
ed
>> >> >> failure
>> >> >> which represents a known bug/issue.
>> >> >>     To make the test pass, fix the bug ;)
>> >> >>
>> >> >> b) others depend on your db, but for the moment I only have
>> >> >> failureExpected methods.
>> >> >>
>> >> >> > 2. Why do you keep test files in strange org.hibernate.test
>> >> package?
>> >> >> > Shouldn't it be same package as sources (e.g. org.hibernate...=
)
>> >> >>
>> >> >> Not strange at all and there is no need to have them in the same
>> >> >> package.
>> >> >> Alot of our tests is "usecase" based tests which does not fit 10=
0%
>> >> into
>> >>
>> >> >> the implmentation "layout".
>> >> >>
>> >> >> --
>> >> >> --
>> >> >> Max Rydahl Andersen
>> >> >> callto://max.rydahl.andersen
>> >> >>
>> >> >> Hibernate
>> >> >> ma...@hi...
>> >> >> http://hibernate.org
>> >> >>
>> >> >> JBoss Inc
>> >> >> max...@jb...
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >> --
>> >> Max Rydahl Andersen
>> >> callto://max.rydahl.andersen
>> >>
>> >> Hibernate
>> >> ma...@hi...
>> >> http://hibernate.org
>> >>
>> >> JBoss Inc
>> >> max...@jb...
>> >>
>>
>>
>>
>> --
>> --
>> Max Rydahl Andersen
>> callto://max.rydahl.andersen
>>
>> Hibernate
>> ma...@hi...
>> http://hibernate.org
>>
>> JBoss Inc
>> max...@jb...
>>



--=20
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
ma...@hi...
http://hibernate.org

JBoss Inc
max...@jb...