incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: JEUT Champion Recruitment
Date Fri, 16 May 2008 13:11:46 GMT
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


Mime
View raw message