Some developers treat testing like flossing - with great reluctance or not at all. But testing is a key part of the software development process, and prevents software decay. In this chapter 4 excerpt, taken from "POJOs in Action," Chris Richardson describes the different kinds of ORM bugs and how to write tests to detect them. He describes which aspects of the O/R mapping must be tested against the database and which other aspects can be tested without a database in order to minimize test execution time. Read Testing a persistent domain model.

Thanks for that insight. Before this moment I had never considered testing any of the software I create. But now I understand. And I think this new understanding is going to change my career.

>

Thanks for that insight. Before this moment I had never considered testing any of the software I create. But now I understand.

And I think this new understanding is going to change my career.

Leading market research shows that 75% of failed software projects fail during testing, and 95% of destroyed careers are the result of being the messenger of bad news. Therefore, 9 out of 10 management consulting companies recommend eliminating testing as a means of ensuring project success. In addition, 4 out of 5 career counseling consultants recommend not doing anything that could lead to you knowing something that management does not want to hear. So it may change your career, but the question is in what way.

95% of statistics aren't believable unless you link to the source.

First, I am noticing an increasing number of articles on persistence on TSS. And, as usual, I always find people arriving now where many others where some years ago. As far the article is concerned, I have to disagree with the approach proposed (testing first the mapping). In fact, you have to test the domain first, regardless the mapping. But, I understand the difficulties using some ORM tools with reduced capabilities. As I rather frequently try to point out, JDO gives the right flexibility to achieve the goal of separately testing the logic of the domain from the relational mapping issues. In fact, JDO (well this should be well-known at this point) is not an ORM tool, but is storage agnostic. This "little feature" makes a huge difference if you use a zero-mapping JDO implementation (there are several) to develop and test **totally** you domain. Then you develop you mapping scheme that can be tested having a solid logic verification step already performed. It must be realised that: persistence != ORM Domain business rules != specific storage engine JDO allows that, JPA no. Guido

As far the article is concerned, I have to disagree with the approach proposed (testing first the mapping).
In fact, you have to test the domain first, regardless the mapping.


Guido

Of course you should test the domain first and then persistence layer. This article is an excerpt of chapter 4, which covers ORM related issues. The previous chapter Chapter 3 describes how to develop and test a domain model (using TDD). Chris

First, I am noticing an increasing number of articles on persistence on TSS.
And, as usual, I always find people arriving now where many others where some years ago.

Aside from your JDO I very much like to comment on this: People grow older and youngers replace olders every now and then. There's hell a lot to learn and to experience for everyone involved in software development processes, often enough you get many years older through it. That's what junior and senior is about after all. Glad you think to be a senior for a longer time already ;-)

First, I am noticing an increasing number of articles on persistence on TSS.
And, as usual, I always find people arriving now where many others where some years ago.

Aside from your JDO I very much like to comment on this: People grow older and youngers replace olders every now and then.
There's hell a lot to learn and to experience for everyone involved in software development processes, often enough you get many years older through it. That's what junior and senior is about after all. Glad you think to be a senior for a longer time already ;-)

It was not referred to myself. And the issue was not the learning evolution (that is quite normal) but rather reinventing the wheel. Announcing to the world the great discovery. And it's OK too, but it's OK also to try to re-establish a minimum of truth. Guido.

... It must be realised that:
persistence != ORM
Domain business rules != specific storage engine

JDO allows that, JPA no.


Guido

Really?! Do not you confuse much hyped JDO's storage agnosticism promise with business level persistence?

...
It must be realised that:
persistence != ORM
Domain business rules != specific storage engine

JDO allows that, JPA no.


Guido

Really?!

Do not you confuse much hyped JDO's storage agnosticism promise with business level persistence?

Promise ? No reality ? business level persistence? Pls, an example because I don't thing we have a common vocabulary for the term. Anyway, I can hardly imagine a "business level" being RDBMS-aware. Guido

A variety of bugs can lurk in the O/R mapping, including the following: * Missing mapping for a field * References to nonexistent tables or columns * Database constraints that prevent objects from being inserted, updated, or deleted * Queries that are invalid

Those bugs are reliably eliminated by Code Generation. Alas, I must admit simply starting a CG is not as cool as writing a bunch of XML files or annotations by hand and debugging them later.

A variety of bugs can lurk in the O/R mapping, including the following:
* Missing mapping for a field
* References to nonexistent tables or columns
* Database constraints that prevent objects from being inserted, updated, or deleted
* Queries that are invalid

Those bugs are reliably eliminated by Code Generation. Alas, I must admit simply starting a CG is not as cool as writing a bunch of XML files or annotations by hand and debugging them later.

Yes, and bugs are then reliably introduced in the model you use for code generation :-) Regards, Dirk

Yes, and bugs are then reliably introduced in the model you use for code generation

Which model? The code is generated from the database schema. Anyone who uses complex 'mapping' configurations clearly misses the point.

Which model? The code is generated from the database schema.

OK, in this case your DB schema is your model and you have a trivial mapping between OO and RDBMS. I agree, that in this case it is very hard to indroduce bugs at the model-level (at least with respect to code generation).

Anyone who uses complex 'mapping' configurations clearly misses the point.

I would not say that they miss the point. There are situations where you cannot have a trivial mapping: - Existing legacy DB: You build your system on top of an existing DB (or even worse: multiple DBs). I have been in so many projects where this was the case. Creating your object model as a 1:1 mapping usually does not make sense, then (at least for the DB schemata I have seen in those projects). If you are building your system from scratch, you are in a very lucky situation. Unfortunately, this does not happen too often (as far as I can tell from my experience). - Neccessary DB schema optimization, e.g due to performance issues. Object models very often have a different normalization level than your database after such optimizations. Regards, Dirk

...Chris Richardson describes the different kinds of ORM bugs...

So if I don't use an ORM tool I won't have to worry about these ORM bugs, right? Sweet!