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
