BTW, if that turns to be the case, you can still collaborate with
OpenJPA and Cayenne projects @Apache to provide similar functionality.
Andrus
On May 16, 2008, at 9:30 AM, Alexis Willemyns wrote:
So, with the solution of "hibernate.hbm2ddl.auto=validate", you
don't need
to write a unit test? If it's the case, the JEUT framework doesn't
have any
sense. I will test this solution!
2008/5/16, James Carman <[EMAIL PROTECTED]>:
This sort of thing should be built into the ORM vendor's
implementation. It is with Hibernate. If you set
hibernate.hbm2ddl.auto=verify, it will make sure the database is set
up correctly based on the mapping settings your application
specifies.
On Fri, May 16, 2008 at 7:22 AM, Alexis Willemyns
<[EMAIL PROTECTED]> wrote:
No I don't think it. The goal is not to test the implementation
(Hibernate,
Toplink, or another one...) of the JPA specification!
Imagine the next case. You have a database engineer, who is for
example a
Oracle specialist, and you have a backend developper. The db
engineer has
the responsability to create manually the the db and the associated
tables.
On another side, the backend developper is responsible of the
devolpment
of
entities (pojos) and he must use the JPA specification. So he will
add
annotations like @Entity, @Id, @Column, etc...
Now the backend developer wants to check that his mapping matches
with
the
work of the db engineer. For example, if he defined a column
'name', he
want
to ensure that there is a column 'name' defined by the db
engineer, that
the
length is the same, that the unique and nullable factors are the
same,
and
so on... If he want to do that, he must write a unit test, and in
this
test,
persist an instance of the entity, and see if there is an error
reported
by
the JPA implementation. JEUT does the job for you.
When you said that it will be good that the framework makes sure
that the
class has the @Entity annotation, etc,... all these errors will be
throwed
by the JPA implementation. The goal is not to have an integration
test,
or
to test the JPA implementation, but it's to check the synchonization
between
the Java pojos (entities) and the physical tables. If the 'name'
column
is
defined as nullable=false via an JPA annotation, we want to be
sure that
in
the table defined by the db engineer, the column is defined with
null=false.
So for this, in the automated tests of JEUT, an entity with the
'name'
field
value set to null is persisted and an exception is expected. If
there is
catched exception (throwed by the persistence implementation), the
test
is a
real success. But if there is no catched exception, it means that
the db
engineer didn't define the column with null=false, and the test
fails!
Here is another example. In JPA, you can create date, time and
timestamp
via
@Temporal annotation. If the backend developer defines a column with
temporal type as date and the db engineer defines the column with
time
type,
all the information about the day, the month and the year are
lost. So
JEUT
tests the matching for the dates, and will find the previous error
of
mapping.
JEUT is compatible all db server, the framework will use the
META-INF/persistence.xml defined in the test source folder in the
application of the user. So the user can test with the oracle db,
hsqldb,
derby, mysql,...
It's not easy to explain!
Is it more clear?
Alexis
2008/5/16, James Carman <[EMAIL PROTECTED]>:
At that point, aren't you just testing that the ORM implementation
"works"? Wouldn't it be better to make unit tests that test the
values of the annotations at runtime? Stuff like:
1. Make sure class X has the @Entity annotation.
2. Make sure its "id" property has the @Id annotation.
3. Make sure the getter for property "foo" has the @Basic
annotation
marking it as required.
4. Make sure the getter for property "foo" has the @Column
annotation
making it saved in the "FOO" column with length 255
If you want to test that the data is actually getting to the
database,
I'd argue that isn't really a unit test, but an "integration test."
Now to test queries you write, you'd probably want to use something
like HSQLDB to make sure you're getting back the correct data (load
some known test data before running tests of course).
On Fri, May 16, 2008 at 6:27 AM, Alexis Willemyns
<[EMAIL PROTECTED]> wrote:
On a technical note, the best solution is to explain you an
example.
As
for
every layer in an application, unit tests are welcome. This is too
true
for
the entities mapped via JPA. So if you want to test an entity, you
will
create an unit test class (for example with JUnit). In this
class, you
will
add some tests. For example, you will write a test that create an
instance
of the entity, set values, persist the entity, retrieve the
entity,
and
check if the retrieved object is exactly the same as the persisted
entity.
It allows you to control that your annotations are matching the
definition
of the real table in the database. You can do extra tests: check
the
nullable attribute, the length attribute, the unique
constraints, and
so
on... But if you want to test every aspect of your entity, you
will
write
a
big piece of code for each entity! If you have a model with 10,
20 or
more
entities, you see directly the quantity of work. JEUT is
designed to
automate for you the testing of an entity. You have just to
create a
test
class that extends a specific JEUT test class and all the work
is done
for
you. The framework uses the annotations discovered via
reflection API
or
the
XML files (orm.xml).
Do you understand the goal of JEUT?
2008/5/15, Andrus Adamchik <[EMAIL PROTECTED]>:
Hi Alexis,
I think it would really help if you started developing in the
open
using
one of the free open source sites. This would provide the project
history to
a potential Champion, including access to the source code and
general
feel
of whether you are really interested in building community around
your
code.
On a technical note, what exactly does this framework test? Is
this
regression testing (i.e. checking that the ORM schema matches the
actual
DB
schema), or is there a value beyond that? We had a similar
framework
submitted to the Cayenne project some time back, and I could
never
understand what exactly is being tested.
Andrus
On May 15, 2008, at 9:57 AM, Alexis Willemyns wrote:
Hello all,
I was a little bit hesitant before posting this project
proposition.
But
let's go! I hope that this attempt will be a success.
JEUT stands for "JPA Entity Unit Test" and is currently in
development.
So
there is no public website and the code is ended up to 70%.
JEUT is
a
testing framework for JPA entities and its main goal is to
automate
the
test
of entities without the need to write long and boring home
tests.
The mission is to provide a framework which is able to test the
matching
between entities using annotations and/or xml descriptors and
the
real
database. A framework 100% compliant with all the existing
annotations
in
JPA, for the current version 1 (and the future version 2... in
the
future).
JEUT analyzes all the annotations and creates instances of
entites
with
random values. It tries to persist these instances via the
entity
manager
and reports the problems if existing. JEUT can be used as an
extension
of
JUnit or TestNG, or maybe all others test frameworks.
For the moment, the team is only composed with me, and I have
discussed
with
my self about what is means to become an Apacha project. I am
aware
what
are
the conditions, responsabilities and impacts to become an Apache
project.
I
am looking a Champion to go in the proposal phase (if the
proposal
makes
sense) and to build a community around JEUT.
Thank you for any feedback and recommendations (and sorry for my
english
coming from Belgium).
I look forward to your responses.
Regards,
Alexis Willemyns
JEUT project founder
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: general-
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
