Menu
▾
▴
hibernate-devel
|
From: Szczepan F. <szc...@gm...> - 2006-06-07 21:23:13
|
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 |
|
From: Max R. A. <max...@jb...> - 2006-06-08 13:25:33
|
> 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
ma...@hi...
http://hibernate.org
JBoss Inc
max...@jb...
|
|
From: Szczepan F. <szc...@gm...> - 2006-06-08 22:00:26
|
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 non public methods, you cannot instantiate some classes etc. Don't you have a refactoring plan to remove test subpackage? Thanks, Szczepan On 6/8/06, Max Rydahl Andersen <max...@jb...> 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 > ma...@hi... > http://hibernate.org > > JBoss Inc > max...@jb... > |
|
From: Christian B. <chr...@jb...> - 2006-06-09 05:13:51
|
On Jun 9, 2006, at 12:00 AM, Szczepan Faber wrote: > Don't you have a refactoring plan to remove test subpackage? No, we don't. Really, tests in a test package are not surprising at all. |
|
From: Max R. A. <max...@jb...> - 2006-06-09 07:07:11
|
> 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 <max...@jb...> 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 >> ma...@hi... >> http://hibernate.org >> >> JBoss Inc >> max...@jb... >> -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
|
From: Szczepan F. <szc...@gm...> - 2006-06-09 16:07:48
|
> 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... 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. > > 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 <max...@jb...> 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 > >> ma...@hi... > >> http://hibernate.org > >> > >> JBoss Inc > >> max...@jb... > >> > > > > -- > -- > Max Rydahl Andersen > callto://max.rydahl.andersen > > Hibernate > ma...@hi... > http://hibernate.org > > JBoss Inc > max...@jb... > |
|
From: Christian B. <chr...@jb...> - 2006-06-09 16:28:31
|
On Jun 9, 2006, at 6:07 PM, Szczepan Faber wrote: > Whatever you say, the failing tests / unreasonable test packaging > just impact the project credibility. This is the most bizarre thing I've heard in quite a while... |
|
From: Max R. A. <max...@jb...> - 2006-06-09 17:03:33
|
>> 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 <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. >> > 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 <max...@jb...> 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 >> >> ma...@hi... >> >> http://hibernate.org >> >> >> >> JBoss Inc >> >> max...@jb... >> >> >> >> >> >> -- >> -- >> 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 max...@jb... |
|
From: Szczepan F. <szc...@gm...> - 2006-06-10 11:48:08
|
> 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 ar= e we thinking here=85 ha ha ha :) Of course you should test non-happy path / expected failure / exception condition. But creating 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 comparin= g 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=85 Well, lets just say I now have a severe impact= ing 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 correspondin= g 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) sinc= e 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 t= o update testcase... Bug should be covered with test, then fixed, then checke= d 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 o= f 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 Faber On 6/9/06, Max Rydahl Andersen <max...@jb...> wrote: > > > >> The day you write a (needed and usefull!) unittest that is not possibl= e > >> 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 tha= t > 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 <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. > >> > Unreasonable > >> > subpackage makes it hard to write real unit test, you cannot test no= n > >> > 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 possibl= e > >> in our current setup then lets talk ;) > >> > >> /max > >> > >> > > >> > Thanks, > >> > Szczepan > >> > > >> > > >> > On 6/8/06, Max Rydahl Andersen <max...@jb...> 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 > >> >> ma...@hi... > >> >> http://hibernate.org > >> >> > >> >> JBoss Inc > >> >> max...@jb... > >> >> > >> > >> > >> > >> -- > >> -- > >> 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 > max...@jb... > |
|
From: Max R. A. <max...@jb...> - 2006-06-10 17:50:25
|
>> 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= =20 >> are > we thinking here=E2=80=A6 > How > can developer know if the codebase in svn is not broken? - only by =20 > comparing > list of failures with list of expected failures. And you guys have to =20 > 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 =20 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 C= I > based environment. I see no reason of creating only testcase (w/o fix) = =20 > 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 =20 > have to > update testcase... Bug should be covered with test, then fixed, then =20 > 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 =20 > output of > failing testcase. If it's working for you - that's great. But in my =20 > opinion > developer should have a clear understanding of stable code base which i= s > 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= =20 > :) If you looked at the tests you would see why they are not in seperate =20 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 =20 unittest framework we are trying to cope with. /max > Thanks, > Szczepan Faber > > On 6/9/06, Max Rydahl Andersen <max...@jb...> wrote: >> >> >> >> 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 >> > 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 = =20 >> 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 ju= st >> > impact the project credibility. But it's just my opinion and my >> > collegues. >> >> unreasonable test packaging ? Nothing *prevents* you from using anothe= r >> 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 soun= ds >> like you want >> us to hide the fact we know some part has a bug/issue ? how is that fo= r >> credibility ? >> >> /max >> >> > 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 =20 >> 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= =20 >> non >> >> > public methods, you cannot instantiate some classes etc. Don't yo= u >> >> 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 =20 >> possible >> >> in our current setup then lets talk ;) >> >> >> >> /max >> >> >> >> > >> >> > Thanks, >> >> > Szczepan >> >> > >> >> > >> >> > On 6/8/06, Max Rydahl Andersen <max...@jb...> wrote: >> >> >> >> >> >> > 1. Why there are about 10 failing test after getting project =20 >> from >> >> svn? >> >> >> >> >> >> a) if the method ends in "FailureExpected", then it is an expect= ed >> >> >> 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 10= 0% >> >> into >> >> >> >> >> 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 >> >> max...@jb... >> >> >> >> >> >> -- >> -- >> Max Rydahl Andersen >> callto://max.rydahl.andersen >> >> Hibernate >> ma...@hi... >> http://hibernate.org >> >> JBoss Inc >> max...@jb... >> --=20 -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate ma...@hi... http://hibernate.org JBoss Inc max...@jb... |
×
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