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