:[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 the bug we could actually
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
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
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
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
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
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
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
: [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 what just works.
reasons
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
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
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
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
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
___
hibernate-devel mailing list
14 matches
Mail list logo
