[Hibernate] hibernate-mysql-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-mysql-testsuite?log=log20060611015557 TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:121: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:77: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 06/11/2006 01:55:57Time to build: 35 minutes 54 seconds Unit Tests: (846) Total Errors and Failures: (51)testParameterTypeMismatchFailsorg.hibernate.test.hql.ASTParserLoadingTesttestCollectionFetchWithDistinctionAndLimitorg.hibernate.test.hql.ASTParserLoadingTesttestTempTableGenerationIsolationorg.hibernate.test.hql.BulkManipulationTesttestSimpleInsertorg.hibernate.test.hql.BulkManipulationTesttestSimpleNativeSQLInsertorg.hibernate.test.hql.BulkManipulationTesttestInsertWithManyToOneorg.hibernate.test.hql.BulkManipulationTesttestInsertWithMismatchedTypesorg.hibernate.test.hql.BulkManipulationTesttestInsertIntoSuperclassPropertiesFailsorg.hibernate.test.hql.BulkManipulationTesttestInsertAcrossMappedJoinFailsorg.hibernate.test.hql.BulkManipulationTesttestUpdateWithWhereExistsSubqueryorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnComponentorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnManyToOneorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnImplicitJoinFailsorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnAnimalorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnMammalorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullUnionSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullOnJoinedSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnJoinedSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnMappedJoinorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassAbstractRootorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassConcreteSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassLeafSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteWithMetadataWhereFragmentsorg.hibernate.test.hql.BulkManipulationTesttestDeleteRestrictedOnManyToOneorg.hibernate.test.hql.BulkManipulationTesttestCriteriaAggregationReturnTypeFailureExpectedorg.hibernate.test.hql.CriteriaHQLAlignmentTesttestScrollingJoinFetchesForwardorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestScrollingJoinFetchesReverseorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestScrollingJoinFetchesPositioningorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestWithClauseFailsWithFetchorg.hibernate.test.hql.WithClauseTesttestWithClauseorg.hibernate.test.hql.WithClauseTesttestQueryorg.hibernate.test.legacy.FooBarTesttestOneToOneGeneratororg.hibernate.test.legacy.FooBarTesttestReachabilityorg.hibernate.test.legacy.FooBarTesttestVersionedCollectionsorg.hibernate.test.legacy.FooBarTesttestReturnPropertyComponentRenameorg.hibernate.test.legacy.SQLLoaderTesttestOneToManyLinkTableorg.hibernate.test.onetomany.OneToManyTesttestReadOnlyOnProxiesFailureExpectedorg.hibernate.test.readonly.ReadOnlyTesttestAutoDetectAliasingorg.hibernate.test.sql.GeneralTesttestScalarStoredProcedureorg.hibernate.test.sql.MySQLTesttestParameterHandlingorg.hibernate.test.sql.MySQLTesttestEntityStoredProcedureorg.hibernate.test.sql.MySQLTesttestEmptyInListFailureExpectedorg.hibernate.test.hql.HQLTesttestMaxindexHqlFunctionInElementAccessorFailureExpectedorg.hibernate.test.hql.HQLTesttestMultipleElementAccessorOperatorsFailureExpectedorg.hibernate.test.hql.HQLTesttestKeyManyToOneJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestDuplicateExplicitJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestOptimisticLockDirtyDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTesttestOptimisticLockAllDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTest Modifications since last build: (first 50 of 0) ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] hibernate-oracle10-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-oracle10-testsuite?log=log20060611012422 TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:100: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:77: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 06/11/2006 01:24:22Time to build: 22 minutes 26 seconds Unit Tests: (850) Total Errors and Failures: (12)testSequenceIdentityGeneratororg.hibernate.test.generatedkeys.seqidentity.SequenceIdentityTesttestParameterTypeMismatchFailsorg.hibernate.test.hql.ASTParserLoadingTesttestCriteriaAggregationReturnTypeFailureExpectedorg.hibernate.test.hql.CriteriaHQLAlignmentTesttestReturnPropertyComponentRenameorg.hibernate.test.legacy.SQLLoaderTesttestReadOnlyOnProxiesFailureExpectedorg.hibernate.test.readonly.ReadOnlyTesttestEmptyInListFailureExpectedorg.hibernate.test.hql.HQLTesttestMaxindexHqlFunctionInElementAccessorFailureExpectedorg.hibernate.test.hql.HQLTesttestMultipleElementAccessorOperatorsFailureExpectedorg.hibernate.test.hql.HQLTesttestKeyManyToOneJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestDuplicateExplicitJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestOptimisticLockDirtyDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTesttestOptimisticLockAllDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTest Modifications since last build: (first 50 of 0) ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] hibernate-sybase-testsuite Build Timed Out
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-sybase-testsuite?log=log20060610222334 BUILD TIMED OUTAnt Error Message: build timeoutDate of build: 06/10/2006 22:23:34Time to build: Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build: (first 50 of 0) ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] hibernate-timesten-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-timesten-testsuite?log=log20060610220011 TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:93: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:77: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 06/10/2006 22:00:11Time to build: 22 minutes 42 seconds Unit Tests: (848) Total Errors and Failures: (213)testCompositeIdsorg.hibernate.test.cid.CompositeIdTesttestNonLazyFetchorg.hibernate.test.cid.CompositeIdTesttestMultipleCollectionFetchorg.hibernate.test.cid.CompositeIdTesttestUpdateFalseorg.hibernate.test.component.ComponentTesttestComponentorg.hibernate.test.component.ComponentTesttestComponentFormulaQueryorg.hibernate.test.component.ComponentTesttestNamedQueryorg.hibernate.test.component.ComponentTesttestSerializationFailsOnAfterStatementAggressiveReleaseWithOpenResourcesorg.hibernate.test.connections.AggressiveReleaseTesttestQueryScrollingorg.hibernate.test.connections.AggressiveReleaseTesttestConnectedSerializationorg.hibernate.test.connections.AggressiveReleaseTesttestManualDisconnectWithOpenResourcesorg.hibernate.test.connections.AggressiveReleaseTesttestConnectedSerializationorg.hibernate.test.connections.BasicConnectionProviderTesttestManualDisconnectWithOpenResourcesorg.hibernate.test.connections.BasicConnectionProviderTesttestSerializationFailsOnAfterStatementAggressiveReleaseWithOpenResourcesorg.hibernate.test.connections.CurrentSessionConnectionTesttestQueryScrollingorg.hibernate.test.connections.CurrentSessionConnectionTesttestConnectedSerializationorg.hibernate.test.connections.CurrentSessionConnectionTesttestManualDisconnectWithOpenResourcesorg.hibernate.test.connections.CurrentSessionConnectionTesttestConnectedSerializationorg.hibernate.test.connections.SuppliedConnectionTesttestManualDisconnectWithOpenResourcesorg.hibernate.test.connections.SuppliedConnectionTesttestScrollCriteriaorg.hibernate.test.criteria.CriteriaQueryTesttestRestrictionOnSubclassCollectionorg.hibernate.test.criteria.CriteriaQueryTesttestClassPropertyorg.hibernate.test.criteria.CriteriaQueryTesttestCompositeUserTypeorg.hibernate.test.cut.CompositeUserTypeTesttestDom4jorg.hibernate.test.dom4j.Dom4jTesttestMapIndexEmisionorg.hibernate.test.dom4j.Dom4jTesttestOrphanDeleteorg.hibernate.test.extralazy.ExtraLazyTesttestIndexFormulaMaporg.hibernate.test.extralazy.ExtraLazyTesttestJdkEnumStyleEnumConstantorg.hibernate.test.hql.ASTParserLoadingTesttestParameterTypeMismatchFailsorg.hibernate.test.hql.ASTParserLoadingTesttestCollectionJoinsInSubselectorg.hibernate.test.hql.ASTParserLoadingTesttestCollectionFetchWithDistinctionAndLimitorg.hibernate.test.hql.ASTParserLoadingTesttestNestedCollectionFetchorg.hibernate.test.hql.ASTParserLoadingTesttestSelectClauseSubselectorg.hibernate.test.hql.ASTParserLoadingTesttestImplicitPolymorphismorg.hibernate.test.hql.ASTParserLoadingTesttestCoalesceorg.hibernate.test.hql.ASTParserLoadingTesttestStrorg.hibernate.test.hql.ASTParserLoadingTesttestCastorg.hibernate.test.hql.ASTParserLoadingTesttestExtractorg.hibernate.test.hql.ASTParserLoadingTesttestOneToManyFilterorg.hibernate.test.hql.ASTParserLoadingTesttestSelectExpressionsorg.hibernate.test.hql.ASTParserLoadingTesttestWhereorg.hibernate.test.hql.ASTParserLoadingTesttestEntityFetchingorg.hibernate.test.hql.ASTParserLoadingTesttestCollectionFetchingorg.hibernate.test.hql.ASTParserLoadingTesttestStandardFunctionsorg.hibernate.test.hql.ASTParserLoadingTesttestDynamicInstantiationQueriesorg.hibernate.test.hql.ASTParserLoadingTesttestResultTransformerScalarQueriesorg.hibernate.test.hql.ASTParserLoadingTesttestResultTransformerEntityQueriesorg.hibernate.test.hql.ASTParserLoadingTesttestEJBQLFunctionsorg.hibernate.test.hql.ASTParserLoadingTesttestSubselectBetweenorg.hibernate.test.hql.ASTParserLoadingTesttestTempTableGenerationIsolationorg.hibernate.test.hql.BulkManipulationTesttestSimpleInsertorg.hibernate.test.hql.BulkManipulationTesttestSimpleNativeSQLInsertorg.hibernate.test.hql.BulkManipulationTesttestInsertWithManyToOneorg.hibernate.test.hql.BulkManipulationTesttestInsertWithMismatchedTypesorg.hibernate.test.hql.BulkManipulationTesttestInsertIntoSuperclassPropertiesFailsorg.hibernate.test.hql.BulkManipulationTesttestInsertAcrossMappedJoinFailsorg.hibernate.test.hql.BulkManipulationTesttestInsertWithGeneratedIdorg.hibernate.test.hql.BulkManipulationTesttestInsertWithGeneratedVersionAndIdorg.hibernate.test.hql.BulkManipulationTesttestInsertWithGeneratedTimestampVersionorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnAnimalorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnMa
Re: [Hibernate] questions regarding development setup
JUnit 4.x has @Ignore annotation.On 6/10/06, Scott M Stark <[EMAIL PROTECTED]> wrote: Then we need to fix it.http://jira.jboss.com/jira/browse/JBQA-383 > -Original Message-> From: Max Andersen> Sent: Saturday, June 10, 2006 10:21 AM> To: Scott M Stark; Szczepan Faber> Cc: hibernate-devel@lists.sourceforge.net> Subject: RE: [Hibernate] questions regarding development setup>>> Yes, but no such thing exist AFAIK. That is why we introduced> this failureExpected notion. >> /max ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
Then we need to fix it. http://jira.jboss.com/jira/browse/JBQA-383 > -Original Message- > From: Max Andersen > Sent: Saturday, June 10, 2006 10:21 AM > To: Scott M Stark; Szczepan Faber > Cc: hibernate-devel@lists.sourceforge.net > Subject: RE: [Hibernate] questions regarding development setup > > > Yes, but no such thing exist AFAIK. That is why we introduced > this failureExpected notion. > > /max ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
>> 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
Re: [Hibernate] questions regarding development setup
Title: RE: [Hibernate] questions regarding development setup Yes, but no such thing exist AFAIK. That is why we introduced this failureExpected notion. /max -Original Message- From: Scott M Stark Sent: Sat 10-06-2006 17:32 To: Max Andersen; Szczepan Faber Cc: hibernate-devel@lists.sourceforge.net Subject: RE: [Hibernate] questions regarding development setup Its more a limitation of the testing environment than project structure. One should be able to annotate known tests as failing at either the test or ci layer to achieve a simple boolean overall result as to whether the testsuite is in an expected state. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Max Rydahl Andersen > Sent: Friday, June 09, 2006 10:03 AM > To: Szczepan Faber > Cc: hibernate-devel@lists.sourceforge.net > Subject: Re: [Hibernate] questions regarding development setup > > > >> 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 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
Its more a limitation of the testing environment than project structure. One should be able to annotate known tests as failing at either the test or ci layer to achieve a simple boolean overall result as to whether the testsuite is in an expected state. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Max Rydahl Andersen > Sent: Friday, June 09, 2006 10:03 AM > To: Szczepan Faber > Cc: hibernate-devel@lists.sourceforge.net > Subject: Re: [Hibernate] questions regarding development setup > > > >> 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 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] questions regarding development setup
> 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 failing test to be patched who-knows-when... Continuous integration server fails every time but it's fine (are you using CI?). All the time you have to check if tests that fail are the one that suppose to fail or not (steals time / error prone)... 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... > And as for a projects choice of how to define tests impacting that projects credibility in > *your projects* mind… Well, lets just say I now have a severe impacting regarding your > project's credibility ;) ha ha :) let's defend my credibility ;p -> Years ago I tried approach of committing into source control deliberately failing test cases corresponding 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? Perhaps you are encouraging contributors to fix bugs by creating failing testcase's? BTW is it working?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. > 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 :) Thanks,Szczepan FaberOn 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 thatdoes 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 - andsince our testsuite contains considerable more test than I've seencompared to otherapplications/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 wantus to hide the fact we know some part has a bug/issue ? how is that forcredibility ?/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".>> >> >> >> -->> >>
[Hibernate] hibernate-mysql-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-mysql-testsuite?log=log20060610045837 TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:121: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:77: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 06/10/2006 04:58:37Time to build: 56 minutes 16 seconds Unit Tests: (846) Total Errors and Failures: (51)testParameterTypeMismatchFailsorg.hibernate.test.hql.ASTParserLoadingTesttestCollectionFetchWithDistinctionAndLimitorg.hibernate.test.hql.ASTParserLoadingTesttestTempTableGenerationIsolationorg.hibernate.test.hql.BulkManipulationTesttestSimpleInsertorg.hibernate.test.hql.BulkManipulationTesttestSimpleNativeSQLInsertorg.hibernate.test.hql.BulkManipulationTesttestInsertWithManyToOneorg.hibernate.test.hql.BulkManipulationTesttestInsertWithMismatchedTypesorg.hibernate.test.hql.BulkManipulationTesttestInsertIntoSuperclassPropertiesFailsorg.hibernate.test.hql.BulkManipulationTesttestInsertAcrossMappedJoinFailsorg.hibernate.test.hql.BulkManipulationTesttestUpdateWithWhereExistsSubqueryorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnComponentorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnManyToOneorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnImplicitJoinFailsorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnAnimalorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnMammalorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullUnionSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullOnJoinedSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnJoinedSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnMappedJoinorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassAbstractRootorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassConcreteSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassLeafSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteWithMetadataWhereFragmentsorg.hibernate.test.hql.BulkManipulationTesttestDeleteRestrictedOnManyToOneorg.hibernate.test.hql.BulkManipulationTesttestCriteriaAggregationReturnTypeFailureExpectedorg.hibernate.test.hql.CriteriaHQLAlignmentTesttestScrollingJoinFetchesForwardorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestScrollingJoinFetchesReverseorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestScrollingJoinFetchesPositioningorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestWithClauseFailsWithFetchorg.hibernate.test.hql.WithClauseTesttestWithClauseorg.hibernate.test.hql.WithClauseTesttestQueryorg.hibernate.test.legacy.FooBarTesttestOneToOneGeneratororg.hibernate.test.legacy.FooBarTesttestReachabilityorg.hibernate.test.legacy.FooBarTesttestVersionedCollectionsorg.hibernate.test.legacy.FooBarTesttestReturnPropertyComponentRenameorg.hibernate.test.legacy.SQLLoaderTesttestOneToManyLinkTableorg.hibernate.test.onetomany.OneToManyTesttestReadOnlyOnProxiesFailureExpectedorg.hibernate.test.readonly.ReadOnlyTesttestAutoDetectAliasingorg.hibernate.test.sql.GeneralTesttestScalarStoredProcedureorg.hibernate.test.sql.MySQLTesttestParameterHandlingorg.hibernate.test.sql.MySQLTesttestEntityStoredProcedureorg.hibernate.test.sql.MySQLTesttestEmptyInListFailureExpectedorg.hibernate.test.hql.HQLTesttestMaxindexHqlFunctionInElementAccessorFailureExpectedorg.hibernate.test.hql.HQLTesttestMultipleElementAccessorOperatorsFailureExpectedorg.hibernate.test.hql.HQLTesttestKeyManyToOneJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestDuplicateExplicitJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestOptimisticLockDirtyDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTesttestOptimisticLockAllDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTest Modifications since last build: (first 50 of 0) ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] hibernate-hsqldb-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-hsqldb-testsuite?log=log20060610044855 TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:86: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:77: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 06/10/2006 04:48:55Time to build: 8 minutes 58 seconds Unit Tests: (848) Total Errors and Failures: (11)testParameterTypeMismatchFailsorg.hibernate.test.hql.ASTParserLoadingTesttestCriteriaAggregationReturnTypeFailureExpectedorg.hibernate.test.hql.CriteriaHQLAlignmentTesttestReturnPropertyComponentRenameorg.hibernate.test.legacy.SQLLoaderTesttestReadOnlyOnProxiesFailureExpectedorg.hibernate.test.readonly.ReadOnlyTesttestEmptyInListFailureExpectedorg.hibernate.test.hql.HQLTesttestMaxindexHqlFunctionInElementAccessorFailureExpectedorg.hibernate.test.hql.HQLTesttestMultipleElementAccessorOperatorsFailureExpectedorg.hibernate.test.hql.HQLTesttestKeyManyToOneJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestDuplicateExplicitJoinFailureExpectedorg.hibernate.test.hql.HQLTesttestOptimisticLockDirtyDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTesttestOptimisticLockAllDeleteFailureExpectedorg.hibernate.test.optlock.OptimisticLockTest Modifications since last build: (first 50 of 0) ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
