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 [EMAIL PROTECTED]
2008/5/16 Andrus Adamchik <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: >> >>> >>> 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 >>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >>>> >>>>> >>>>> 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 >>>>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >>>>>> >>>>>>> >>>>>>> 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: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
