incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexis Willemyns" <alexiswillem...@gmail.com>
Subject Re: JEUT Champion Recruitment
Date Fri, 16 May 2008 13:45:40 GMT
Yes it seems to work perfectly. Is there an equivalent for Toplink of
Oracle?

2008/5/16, James Carman <james@carmanconsulting.com>:
>
> 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
> <alexiswillemyns@gmail.com> 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 <james@carmanconsulting.com>:
> >>
> >> 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
> >> <alexiswillemyns@gmail.com> 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 <james@carmanconsulting.com>:
> >> >>
> >> >> 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
> >> >> <alexiswillemyns@gmail.com> 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 <andrus@objectstyle.org>:
> >> >> >>
> >> >> >> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message