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 : >> >> 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 >> 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 : >>>> >>>> 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 >>>> 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 : >>>>>> >>>>>> 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