PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Erik
BertelsenSent: Sunday, June 11, 2006 12:35 PMTo: Max
AndersenCc: hibernate-devel@lists.sourceforge.netSubject:
Re: [Hibernate] questions regarding development setup
2006/6/11, Max Rydahl Andersen <[EMAIL PROTECTED]>:
as
i mentioned at
On Sun, 11 Jun 2006 18:34:36 +0200, Erik Bertelsen
<[EMAIL PROTECTED]> wrote:
> 2006/6/11, Max Rydahl Andersen <[EMAIL PROTECTED]>:
>>
>>
>>
>> as i mentioned at the bug we could actually implement this by doing a
>> custom impl of HibernateTestCase.runTest()
>>
>> /max
>
>
>
> Hi all,
>
> what
2006/6/11, Max Rydahl Andersen <[EMAIL PROTECTED]>:
as i mentioned at the bug we could actually implement this by doing acustom impl of HibernateTestCase.runTest()/maxHi all,what about a version of runTest() that silently accepts test failures for tests that are expected to fail and report them as
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
&g
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
___
hi
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] q
>> 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 o
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
[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
>
>
> >>
> 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
fa
>> 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
: 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.
> No reason to change w
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...
___
hibernate-devel mailing l
> 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
> 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 te
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.
___
hibernate-devel mailing list
hibernate-devel@lists.sourcef
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 no
> 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
failure
I don't know of any tool that would do this automagically. It might be
something you could start a project with, but after that I'm not sure how
useful such a tool would be.
Personally, I prefer using xdoclet to produce Hibernate mappings, and then
use the Hibernate mappings to produce the DDL (
So I have an update on figuring this out. I got most of it working, there
was a bug in XDoclet with subclass generation (classes outside the package of
the base class were not being found) and with 34 subclasses I hadn't realized
there was an issue. XDoclet CVS has a resolution to this.
Now that
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Subject: Re: [Hibernate] questions about polymorphism
>
> >> Since the subclass is
> completely described this way, is the separate mapping file for the
> subclass
> redundant?
|
| cc: <[EMAIL PROTECTED]>
|
| Subject: RE: [Hibernate] questions about polymorphism
|
>-
>> It seems that if I use "table-per-class", I am going to get hit
with thirty queries every time I do a select of the superclass, is that
correct? <<
Correct
>> But if I use "table-per-subclass" with , I will
get two selects -- one for the superclass result set and one for each table
(or table
23 matches
Mail list logo
