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 Fri, 16 May 2008 13:45:01 GMT
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


Mime
View raw message