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?
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]
_______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
