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