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