>> 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.

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 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 just
> impact the project credibility. But it's just my opinion and my  
> collegues.

unreasonable test packaging ? Nothing *prevents* you from using another  
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 sounds  
like you want
us to hide the fact we know some part has a bug/issue ? how is that for  
credibility ?

/max

> 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]
>>



-- 
--
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

Reply via email to