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 are we thinking here…
And as for a projects choice of how to define
tests impacting that projects credibility in *your
projects* mind… Well, lets just say I now have a severe
impacting regarding your project’s credibility ;)
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Szczepan Faber
Sent: Friday, June 09, 2006 11:08
AM
To: Max Andersen
Cc:
hibernate-devel@lists.sourceforge.net
Subject: Re: [Hibernate] questions
regarding development setup
> The day you write a
(needed and usefull!) unittest that is not possible
> in our current setup then lets talk ;)
I've already created patch with couple testcases using same package layout on
purpose.
> 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 :) ?)
Anyway I will just contribute a patch and let's see what you say...
PS
Whatever you say, the failing tests / unreasonable test packaging just impact
the project credibility. But it's just my opinion and my collegues.
Thanks,
Szczepan
On 6/9/06, Max
Rydahl Andersen <[EMAIL PROTECTED]> wrote:
> b) But what's the reason of making surprising test subpackage (I've never
> seen something like that)? You can still have 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 non
> public methods, you cannot instantiate some classes etc. Don't you 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 possible
in our current setup then lets talk ;)
/max
>
> Thanks,
> Szczepan
>
>
> On 6/8/06, Max Rydahl Andersen <[EMAIL PROTECTED]> wrote:
>>
>> > 1. Why there are about 10 failing test after getting project from
svn?
>>
>> a) if the method ends in "FailureExpected", then it is an
expected
>> 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 100% into
>> the implmentation "layout".
>>
>> --
>> --
>> Max Rydahl Andersen
>> callto://max.rydahl.andersen
>>
>> Hibernate
>> [EMAIL PROTECTED]
>> http://hibernate.org
>>
>> JBoss Inc
>> [EMAIL PROTECTED]
>>
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
|
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
