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