incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: JEUT Champion Recruitment
Date Wed, 21 May 2008 06:43:35 GMT
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 <andrus@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 <james@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
>>>> <alexiswillemyns@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 <james@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
>>>>>> <alexiswillemyns@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 <andrus@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


Mime
View raw message