You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Alexis Willemyns <al...@gmail.com> on 2008/05/15 15:57:05 UTC
JEUT Champion Recruitment
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
Re: JEUT Champion Recruitment
Posted by Alexis Willemyns <al...@gmail.com>.
Yes of course, it's in the planning. But I will put a full version of the
JEUT framework on the net. It will be probably a hosting with source forge
and the use of Maven. Once done, I will give the url.
Alexis
2008/5/16, Bertrand Delacretaz <bd...@apache.org>:
>
> Hi Alexis,
>
> On Thu, May 15, 2008 at 3:57 PM, Alexis Willemyns
> <al...@gmail.com> wrote:
> >... there is no public website and the code is ended up to 70%....
>
> Like Andrus, I would suggest that you first put make your code and
> ideas visible to others using one of the open source hosting sites.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: JEUT Champion Recruitment
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Alexis,
On Thu, May 15, 2008 at 3:57 PM, Alexis Willemyns
<al...@gmail.com> wrote:
>... there is no public website and the code is ended up to 70%....
Like Andrus, I would suggest that you first put make your code and
ideas visible to others using one of the open source hosting sites.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by Alexis Willemyns <al...@gmail.com>.
"it is a model regression testing tool"
Yes, but I don't like the word "regression". In a first step, it's
a "checking" testing framework, and in a second step, it becomes a
"regression" testing framework in the lifecyle of an application.
I am happy that my some examples help you to have a deeper view of the JEUT
goals.
Thanks for your interest.
Alexis
2008/5/16, Andrus Adamchik <an...@objectstyle.org>:
>
> Hi Alexis,
>
> Thanks for clarifying. It matches my earlier understanding - it is a model
> regression testing tool. I am not saying it is not useful, just wanted to
> define the terms so that we have an understanding of what JEUT is.
>
> Andrus
>
>
> On May 16, 2008, at 6:27 AM, Alexis Willemyns 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 <an...@objectstyle.org>:
>>
>>>
>>> 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: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: JEUT Champion Recruitment
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Alexis,
Thanks for clarifying. It matches my earlier understanding - it is a
model regression testing tool. I am not saying it is not useful, just
wanted to define the terms so that we have an understanding of what
JEUT is.
Andrus
On May 16, 2008, at 6:27 AM, Alexis Willemyns 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 <an...@objectstyle.org>:
>>
>> 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: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Alexis,
Sorry, was on the road and unable to reply earlier. If you want to
discuss where that might fit with Cayenne, I'd suggest to subscribe to
Cayenne dev list and start a discussion there.
Andrus
On May 16, 2008, at 11:05 PM, Alexis Willemyns wrote:
> What a good idea! I am really interested by the persistence layer.
> It would
> be a great pleasure to work on the Cayenne project. If you desire,
> we can
> speak about that by private email. Contact me at alexiswillemyns@gmail.com
>
> 2008/5/16 Andrus Adamchik <an...@objectstyle.org>:
>
>> 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 <ja...@carmanconsulting.com>:
>>>
>>>>
>>>> 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
>>>> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>>>>
>>>>>>
>>>>>> 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
>>>>>> <al...@gmail.com> 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 <an...@objectstyle.org>:
>>>>>>>
>>>>>>>>
>>>>>>>> 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: general-
>>>>>>>> unsubscribe@incubator.apache.org
>>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: general-
>>>>>> help@incubator.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by Alexis Willemyns <al...@gmail.com>.
What a good idea! I am really interested by the persistence layer. It would
be a great pleasure to work on the Cayenne project. If you desire, we can
speak about that by private email. Contact me at alexiswillemyns@gmail.com
2008/5/16 Andrus Adamchik <an...@objectstyle.org>:
> 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 <ja...@carmanconsulting.com>:
>>
>>>
>>> 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
>>> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>>>
>>>>>
>>>>> 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
>>>>> <al...@gmail.com> 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 <an...@objectstyle.org>:
>>>>>>
>>>>>>>
>>>>>>> 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: general-unsubscribe@incubator.apache.org
>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: JEUT Champion Recruitment
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <ja...@carmanconsulting.com>:
>>
>> 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
>> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>>>
>>>> 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
>>>> <al...@gmail.com> 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 <an...@objectstyle.org>:
>>>>>>
>>>>>> 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: general-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: general-
>>>>>> help@incubator.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by James Carman <ja...@carmanconsulting.com>.
I do not use Toplink, so I wouldn't be a good person to answer that
question. I'm glad the Hibernate stuff could help you, though. We've
found that to be a lifesaver in our project.
On Fri, May 16, 2008 at 9:45 AM, Alexis Willemyns
<al...@gmail.com> wrote:
> Yes it seems to work perfectly. Is there an equivalent for Toplink of
> Oracle?
>
> 2008/5/16, James Carman <ja...@carmanconsulting.com>:
>>
>> Well, one of our unit tests is called TestTargetDatabaseSchema and in
>> that test I do:
>>
>> @Test
>> public void verifySchema()
>> {
>> SchemaValidator validator = new SchemaValidator(getConfiguration());
>> validator.validate();
>> }
>>
>> We also found it useful to actually spit out the DDL that hibernate
>> would use to generate the schema itself (if you use
>> hibernate.hbm2ddl.auto=create-drop):
>>
>> @Test
>> public void exportSchema()
>> {
>> final SchemaExport export = new SchemaExport(getConfiguration());
>> final File outputFile = new File("target/sql/schema.sql");
>> outputFile.getParentFile().mkdirs();
>> export.setOutputFile(outputFile.getAbsolutePath());
>> export.create(false,false);
>> }
>>
>> We use maven2, so the target directory is a common location for build
>> artifacts. The getConfiguration() method merely sets up the Hibernate
>> configuration object. Hope this helps!
>>
>> On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
>> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>> >>
>> >> 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
>> >> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>> >> >>
>> >> >> 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
>> >> >> <al...@gmail.com> 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 <an...@objectstyle.org>:
>> >> >> >>
>> >> >> >> 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: general-unsubscribe@incubator.apache.org
>> >> >> >> For additional commands, e-mail:
>> general-help@incubator.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by Alexis Willemyns <al...@gmail.com>.
Yes it seems to work perfectly. Is there an equivalent for Toplink of
Oracle?
2008/5/16, James Carman <ja...@carmanconsulting.com>:
>
> Well, one of our unit tests is called TestTargetDatabaseSchema and in
> that test I do:
>
> @Test
> public void verifySchema()
> {
> SchemaValidator validator = new SchemaValidator(getConfiguration());
> validator.validate();
> }
>
> We also found it useful to actually spit out the DDL that hibernate
> would use to generate the schema itself (if you use
> hibernate.hbm2ddl.auto=create-drop):
>
> @Test
> public void exportSchema()
> {
> final SchemaExport export = new SchemaExport(getConfiguration());
> final File outputFile = new File("target/sql/schema.sql");
> outputFile.getParentFile().mkdirs();
> export.setOutputFile(outputFile.getAbsolutePath());
> export.create(false,false);
> }
>
> We use maven2, so the target directory is a common location for build
> artifacts. The getConfiguration() method merely sets up the Hibernate
> configuration object. Hope this helps!
>
> On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
> >>
> >> 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
> >> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
> >> >>
> >> >> 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
> >> >> <al...@gmail.com> 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 <an...@objectstyle.org>:
> >> >> >>
> >> >> >> 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: general-unsubscribe@incubator.apache.org
> >> >> >> For additional commands, e-mail:
> general-help@incubator.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail: general-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: JEUT Champion Recruitment
Posted by James Carman <ja...@carmanconsulting.com>.
Well, one of our unit tests is called TestTargetDatabaseSchema and in
that test I do:
@Test
public void verifySchema()
{
SchemaValidator validator = new SchemaValidator(getConfiguration());
validator.validate();
}
We also found it useful to actually spit out the DDL that hibernate
would use to generate the schema itself (if you use
hibernate.hbm2ddl.auto=create-drop):
@Test
public void exportSchema()
{
final SchemaExport export = new SchemaExport(getConfiguration());
final File outputFile = new File("target/sql/schema.sql");
outputFile.getParentFile().mkdirs();
export.setOutputFile(outputFile.getAbsolutePath());
export.create(false,false);
}
We use maven2, so the target directory is a common location for build
artifacts. The getConfiguration() method merely sets up the Hibernate
configuration object. Hope this helps!
On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
<al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>
>> 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
>> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>> >>
>> >> 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
>> >> <al...@gmail.com> 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 <an...@objectstyle.org>:
>> >> >>
>> >> >> 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: general-unsubscribe@incubator.apache.org
>> >> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by Alexis Willemyns <al...@gmail.com>.
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 <ja...@carmanconsulting.com>:
>
> 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
> <al...@gmail.com> 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 <ja...@carmanconsulting.com>:
> >>
> >> 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
> >> <al...@gmail.com> 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 <an...@objectstyle.org>:
> >> >>
> >> >> 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: general-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail: general-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: JEUT Champion Recruitment
Posted by James Carman <ja...@carmanconsulting.com>.
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
<al...@gmail.com> 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 <ja...@carmanconsulting.com>:
>>
>> 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
>> <al...@gmail.com> 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 <an...@objectstyle.org>:
>> >>
>> >> 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: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by Alexis Willemyns <al...@gmail.com>.
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 <ja...@carmanconsulting.com>:
>
> 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
> <al...@gmail.com> 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 <an...@objectstyle.org>:
> >>
> >> 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: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: JEUT Champion Recruitment
Posted by James Carman <ja...@carmanconsulting.com>.
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
<al...@gmail.com> 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 <an...@objectstyle.org>:
>>
>> 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: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JEUT Champion Recruitment
Posted by Alexis Willemyns <al...@gmail.com>.
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 <an...@objectstyle.org>:
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: JEUT Champion Recruitment
Posted by Andrus Adamchik <an...@objectstyle.org>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org