>> 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…
> How > can developer know if the codebase in svn is not broken? - only by > comparing > list of failures with list of expected failures. And you guys have to > make > this comparison every time you evaluate someone's patch... It is not optimal, but it is quite easy to see if a method not called failureExpected is failing. We know it is not optimal, but it is better than removing those tests. > to particular log in issue management tool... It just doesn't work in CI > based environment. I see no reason of creating only testcase (w/o fix) > since > you have the information about the bug in jira. You defer the bugfix to > vague future... when something changes regarding the bug on jira you > have to > update testcase... Bug should be covered with test, then fixed, then > checked > into svn... Does having failing testcases of known bugs is a reason to be > proud? Having the tests only in jira make them being deferred even longer. > You may have process of estimation/analysis of a jira log with the > output of > failing testcase. If it's working for you - that's great. But in my > opinion > developer should have a clear understanding of stable code base which is > green color on junit progress bar. And the development should be red -> > green -> refactor not red -> red -> refactor. Again, we prefer to have the failureExpected then none at all. >> And do you rather want us to remove tests for known issues ? > > I'd prefer refactor to separate source folder, perhaps not taking part in > main build and in future not checking into svn without an actual bugfix > :) If you looked at the tests you would see why they are not in seperate classes/folders would add very redundant testcode that is even worse to maintain. Again, as Scott so correctly pointed out; it is a limitation of the unittest framework we are trying to cope with. /max > Thanks, > Szczepan Faber > > On 6/9/06, Max Rydahl Andersen <[EMAIL PROTECTED]> wrote: >> >> >> >> 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] >> -- -- 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
