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…ha ha ha :) Of course you should test non-happy path / expected failure / exception condition. But c
reating
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
a) ok :)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
I've just checked out the project from svn and after running tests, there are 7 failures / 5 errors.Is it normal? :-) How can I be sure that my patch does not break anything?Thanks,Szczepan
___
hibernate-devel mailing list
1. Why there are about 10 failing test after getting project from svn?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...)Thanks,
Szczepan
___
hibernate-devel mailing list
