Re: JEUT Champion Recruitment
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]
Re: JEUT Champion Recruitment
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
Re: JEUT Champion Recruitment
Yes of course, it's in the planning. But I will put a full version of the JEUT framework on the net. It will be probably a hosting with source forge and the use of Maven. Once done, I will give the url. Alexis 2008/5/16, Bertrand Delacretaz [EMAIL PROTECTED]: Hi Alexis, On Thu, May 15, 2008 at 3:57 PM, Alexis Willemyns [EMAIL PROTECTED] wrote: ... there is no public website and the code is ended up to 70% Like Andrus, I would suggest that you first put make your code and ideas visible to others using one of the open source hosting sites. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JEUT Champion Recruitment
it is a model regression testing tool Yes, but I don't like the word regression. In a first step, it's a checking testing framework, and in a second step, it becomes a regression testing framework in the lifecyle of an application. I am happy that my some examples help you to have a deeper view of the JEUT goals. Thanks for your interest. Alexis 2008/5/16, Andrus Adamchik [EMAIL PROTECTED]: Hi Alexis, Thanks for clarifying. It matches my earlier understanding - it is a model regression testing tool. I am not saying it is not useful, just wanted to define the terms so that we have an understanding of what JEUT is. Andrus On 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 [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]
Re: JEUT Champion Recruitment
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
Re: JEUT Champion Recruitment
Yes it seems to work perfectly. Is there an equivalent for Toplink of
Oracle?
2008/5/16, James Carman [EMAIL PROTECTED]:
Well, one of our unit tests is called TestTargetDatabaseSchema and in
that test I do:
@Test
public void verifySchema()
{
SchemaValidator validator = new SchemaValidator(getConfiguration());
validator.validate();
}
We also found it useful to actually spit out the DDL that hibernate
would use to generate the schema itself (if you use
hibernate.hbm2ddl.auto=create-drop):
@Test
public void exportSchema()
{
final SchemaExport export = new SchemaExport(getConfiguration());
final File outputFile = new File(target/sql/schema.sql);
outputFile.getParentFile().mkdirs();
export.setOutputFile(outputFile.getAbsolutePath());
export.create(false,false);
}
We use maven2, so the target directory is a common location for build
artifacts. The getConfiguration() method merely sets up the Hibernate
configuration object. Hope this helps!
On Fri, May 16, 2008 at 9:30 AM, Alexis Willemyns
[EMAIL PROTECTED] 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
Re: JEUT Champion Recruitment
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
JEUT Champion Recruitment
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
