incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexis Willemyns" <alexiswillem...@gmail.com>
Subject Re: JEUT Champion Recruitment
Date Fri, 16 May 2008 20:05:09 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message