Menu
▾
▴
hibernate-devel
|
From: Steve E. <ste...@jb...> - 2006-06-09 16:32:55
|
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... =20 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 ;) =20 ________________________________ From: hib...@li... [mailto:hib...@li...] On Behalf Of Szczepan Faber Sent: Friday, June 09, 2006 11:08 AM To: Max Andersen Cc: hib...@li... Subject: Re: [Hibernate] questions regarding development setup =20 > 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 method / class w/o public constructor. (every day :) ?) Anyway I will just contribute a patch and let's see what you say...=20 PS Whatever you say, the failing tests / unreasonable test packaging just impact the project credibility. But it's just my opinion and my collegues. Thanks, Szczepan On 6/9/06, Max Rydahl Andersen <max...@jb...> 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.=20 > 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?=20 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=20 > > > On 6/8/06, Max Rydahl Andersen <max...@jb...> wrote: >>=20 >> > 1. Why there are about 10 failing test after getting project from svn?=20 >> >> 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 ;)=20 >> >> 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=20 >> the implmentation "layout". >> >> -- >> -- >> Max Rydahl Andersen >> callto://max.rydahl.andersen >> >> Hibernate >> ma...@hi... >> http://hibernate.org >> >> JBoss Inc >> max...@jb... >> -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc=20 max...@jb... =20 |
|
From: Scott M S. <sco...@jb...> - 2006-06-10 15:32:46
|
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: hib...@li...=20 > [mailto:hib...@li...] On=20 > Behalf Of Max Rydahl Andersen > Sent: Friday, June 09, 2006 10:03 AM > To: Szczepan Faber > Cc: hib...@li... > Subject: Re: [Hibernate] questions regarding development setup >=20 >=20 > >> The day you write a (needed and usefull!) unittest that is not=20 > >> possible in our current setup then lets talk ;) > > > > I've already created patch with couple testcases using same package=20 > > layout on purpose. >=20 > ok. >=20 > >> No reason to change what just works. > > > > reasons: every time the developer cannot unit test=20 > non-public method /=20 > > class w/o public constructor. (every day :) ?) >=20 > well, it has never been an issue since we have more than=20 > enough tests that does this, so again it just works. >=20 > > Anyway I will just contribute a patch and let's see what you say... >=20 > ok. >=20 > > PS > > Whatever you say, the failing tests / unreasonable test=20 > packaging just=20 > > impact the project credibility. But it's just my opinion and my=20 > > collegues. >=20 > unreasonable test packaging ? Nothing *prevents* you from=20 > using another layout - and since our testsuite contains=20 > considerable more test than I've seen compared to other=20 > applications/frameworks it doesn't seem to be an issue in=20 > real life vs. =20 > theoretical rants. >=20 > And do you rather want us to remove tests for known issues ?=20 > That sounds like you want us to hide the fact we know some=20 > part has a bug/issue ? how is that for credibility ? >=20 > /max |
|
From: Max A. <max...@jb...> - 2006-06-10 17:22:59
|
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: hib...@li... Subject: RE: [Hibernate] questions regarding development setup =20 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: hib...@li...=20 > [mailto:hib...@li...] On=20 > Behalf Of Max Rydahl Andersen > Sent: Friday, June 09, 2006 10:03 AM > To: Szczepan Faber > Cc: hib...@li... > Subject: Re: [Hibernate] questions regarding development setup >=20 >=20 > >> The day you write a (needed and usefull!) unittest that is not=20 > >> possible in our current setup then lets talk ;) > > > > I've already created patch with couple testcases using same package=20 > > layout on purpose. >=20 > ok. >=20 > >> No reason to change what just works. > > > > reasons: every time the developer cannot unit test=20 > non-public method /=20 > > class w/o public constructor. (every day :) ?) >=20 > well, it has never been an issue since we have more than=20 > enough tests that does this, so again it just works. >=20 > > Anyway I will just contribute a patch and let's see what you say... >=20 > ok. >=20 > > PS > > Whatever you say, the failing tests / unreasonable test=20 > packaging just=20 > > impact the project credibility. But it's just my opinion and my=20 > > collegues. >=20 > unreasonable test packaging ? Nothing *prevents* you from=20 > using another layout - and since our testsuite contains=20 > considerable more test than I've seen compared to other=20 > applications/frameworks it doesn't seem to be an issue in=20 > real life vs. =20 > theoretical rants. >=20 > And do you rather want us to remove tests for known issues ?=20 > That sounds like you want us to hide the fact we know some=20 > part has a bug/issue ? how is that for credibility ? >=20 > /max |
|
From: Scott M S. <sco...@jb...> - 2006-06-10 18:05:08
|
Then we need to fix it. http://jira.jboss.com/jira/browse/JBQA-383=20 > -----Original Message----- > From: Max Andersen=20 > Sent: Saturday, June 10, 2006 10:21 AM > To: Scott M Stark; Szczepan Faber > Cc: hib...@li... > Subject: RE: [Hibernate] questions regarding development setup >=20 >=20 > Yes, but no such thing exist AFAIK. That is why we introduced=20 > this failureExpected notion. >=20 > /max |
|
From: Szczepan F. <szc...@gm...> - 2006-06-10 22:56:42
|
JUnit 4.x has @Ignore annotation. On 6/10/06, Scott M Stark <sco...@jb...> 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: hib...@li... > > Subject: RE: [Hibernate] questions regarding development setup > > > > > > Yes, but no such thing exist AFAIK. That is why we introduced > > this failureExpected notion. > > > > /max > |
|
From: Max R. A. <max...@jb...> - 2006-06-11 16:16:27
|
On Sun, 11 Jun 2006 00:56:38 +0200, Szczepan Faber <szc...@gm...> wrote: > JUnit 4.x has @Ignore annotation. and does not run on jdk 1.4, so what is the point ? :) as i mentioned at the bug we could actually implement this by doing a custom impl of HibernateTestCase.runTest() /max > > On 6/10/06, Scott M Stark <sco...@jb...> 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: hib...@li... >> > Subject: RE: [Hibernate] questions regarding development setup >> > >> > >> > Yes, but no such thing exist AFAIK. That is why we introduced >> > this failureExpected notion. >> > >> > /max >> -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
|
From: Erik B. <ber...@gm...> - 2006-06-11 16:34:41
|
2006/6/11, Max Rydahl Andersen <max...@jb...>: > > > > as i mentioned at the bug we could actually implement this by doing a > custom impl of HibernateTestCase.runTest() > > /max Hi all, what about a version of runTest() that silently accepts test failures for tests that are expected to fail and report them as 'failures' if they suddenly start to succeed. This will have the intended result that a test run is silent if everything works out as expected and if a test that is expected to fail suddenly succeeds, it will show up in the test report. If the success of the test was intentional because the problem was solved, the test should of course be changed to a normal non-failure-expected test. If the success was an unintentional consequence of some code change, then the developer can investigate whether the problem was really solved or just disguised and possibly alter the test. - Erik |
|
From: Max R. A. <max...@jb...> - 2006-06-11 16:45:11
|
On Sun, 11 Jun 2006 18:34:36 +0200, Erik Bertelsen <ber...@gm...> wrote: > 2006/6/11, Max Rydahl Andersen <max...@jb...>: >> >> >> >> as i mentioned at the bug we could actually implement this by doing a >> custom impl of HibernateTestCase.runTest() >> >> /max > > > > Hi all, > > what about a version of runTest() that silently accepts test failures for > tests that are expected to fail and report them as 'failures' if they > suddenly start to succeed. that was the idea. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
|
From: Gavin K. <gav...@jb...> - 2006-06-11 16:48:26
|
Is there some actual problem we are trying to solve here? Because if there is, no-one has pointed it out yet. =20 The point of the failing tests is to remind and nag us to get them fixed. If we hide the failures we remove that incentive. =20 There has been a bunch of handwaving about how this could theoretically be a problem for continuous integration ... except that we are doing continuous integration and it is not causing any problems! =20 It seems there are some people here who have read a couple of books by Kent Beck and think that their job as a software developer is to enforce their Holy Perfect Process on everyone. That's perfectly fine, but we are practical people running an actual serious software project here, and we don't have time for trying to impress people by how aGiLe we are. =20 Thanks for your input, this is the end of the thread. ________________________________ From: hib...@li... [mailto:hib...@li...] On Behalf Of Erik Bertelsen Sent: Sunday, June 11, 2006 12:35 PM To: Max Andersen Cc: hib...@li... Subject: Re: [Hibernate] questions regarding development setup 2006/6/11, Max Rydahl Andersen <max...@jb...>:=20 as i mentioned at the bug we could actually implement this by doing a custom impl of HibernateTestCase.runTest() =09 /max Hi all, what about a version of runTest() that silently accepts test failures for tests that are expected to fail and report them as 'failures' if they suddenly start to succeed.=20 This will have the intended result that a test run is silent if everything works out as expected and if a test that is expected to fail suddenly succeeds, it will show up in the test report. If the success of the test was intentional because the problem was solved, the test should of course be changed to a normal non-failure-expected test. If the success was an unintentional consequence of some code change, then the developer can investigate whether the problem was really solved or just disguised and possibly alter the test.=20 - Erik |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X