> 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