-
Article: Testing a persistent domain model (14 messages)
- Posted by: Regina Lynch
- Posted on: June 22 2006 12:49 EDT
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.Threaded Messages (14)
- ! by Ethan Allen on June 22 2006 14:17 EDT
- Don't be hasty by Erik Engbrecht on June 22 2006 15:37 EDT
- Re: Don't be hasty by Matt Byrne on June 27 2006 04:58 EDT
- Don't be hasty by Erik Engbrecht on June 22 2006 15:37 EDT
- Re: Article: Testing a persistent domain model by Guido Anzuoni on June 22 2006 15:48 EDT
- Re: Article: Testing a persistent domain model by Chris Richardson on June 22 2006 21:18 EDT
- Re: Article: Testing a persistent domain model by Stefan Schubert on June 23 2006 09:44 EDT
- Re: Article: Testing a persistent domain model by Guido Anzuoni on June 23 2006 12:43 EDT
- Re: Article: Testing a persistent domain model by Konstantin Ignatyev on June 23 2006 12:19 EDT
- Re: Article: Testing a persistent domain model by Guido Anzuoni on June 23 2006 12:50 EDT
- Code Genreation vs. Testing by Casual Visitor on June 22 2006 16:24 EDT
- Re: Code Genreation vs. Testing by Dirk Ludwig on June 23 2006 03:09 EDT
-
Re: Code Genreation vs. Testing by Casual Visitor on June 23 2006 04:56 EDT
- Re: Code Genreation vs. Testing by Dirk Ludwig on June 23 2006 09:36 EDT
-
Re: Code Genreation vs. Testing by Casual Visitor on June 23 2006 04:56 EDT
- Re: Code Genreation vs. Testing by Dirk Ludwig on June 23 2006 03:09 EDT
- Re: Article: Testing a persistent domain model by Race Condition on June 23 2006 09:43 EDT
-
![ Go to top ]
- Posted by: Ethan Allen
- Posted on: June 22 2006 14:17 EDT
- in response to Regina Lynch
-
Don't be hasty[ Go to top ]
- Posted by: Erik Engbrecht
- Posted on: June 22 2006 15:37 EDT
- in response to Ethan Allen
>
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.
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. -
Re: Don't be hasty[ Go to top ]
- Posted by: Matt Byrne
- Posted on: June 27 2006 04:58 EDT
- in response to Erik Engbrecht
95% of statistics aren't believable unless you link to the source. -
Re: Article: Testing a persistent domain model[ Go to top ]
- Posted by: Guido Anzuoni
- Posted on: June 22 2006 15:48 EDT
- in response to Regina Lynch
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 -
Re: Article: Testing a persistent domain model[ Go to top ]
- Posted by: Chris Richardson
- Posted on: June 22 2006 21:18 EDT
- in response to Guido Anzuoni
As far the article is concerned, I have to disagree with the approach proposed (testing first the mapping).
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
In fact, you have to test the domain first, regardless the mapping.
Guido -
Re: Article: Testing a persistent domain model[ Go to top ]
- Posted by: Stefan Schubert
- Posted on: June 23 2006 09:44 EDT
- in response to Guido Anzuoni
First, I am noticing an increasing number of articles on persistence on TSS.
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 ;-)
And, as usual, I always find people arriving now where many others where some years ago. -
Re: Article: Testing a persistent domain model[ Go to top ]
- Posted by: Guido Anzuoni
- Posted on: June 23 2006 12:43 EDT
- in response to Stefan Schubert
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.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 ;-) -
Re: Article: Testing a persistent domain model[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: June 23 2006 12:19 EDT
- in response to Guido Anzuoni
... It must be realised that:
Really?! Do not you confuse much hyped JDO's storage agnosticism promise with business level persistence?
persistence != ORM
Domain business rules != specific storage engine
JDO allows that, JPA no.
Guido -
Re: Article: Testing a persistent domain model[ Go to top ]
- Posted by: Guido Anzuoni
- Posted on: June 23 2006 12:50 EDT
- in response to Konstantin Ignatyev
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...
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? -
Code Genreation vs. Testing[ Go to top ]
- Posted by: Casual Visitor
- Posted on: June 22 2006 16:24 EDT
- in response to Regina Lynch
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. -
Re: Code Genreation vs. Testing[ Go to top ]
- Posted by: Dirk Ludwig
- Posted on: June 23 2006 03:09 EDT
- in response to Casual Visitor
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. -
Re: Code Genreation vs. Testing[ Go to top ]
- Posted by: Casual Visitor
- Posted on: June 23 2006 04:56 EDT
- in response to Dirk Ludwig
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. -
Re: Code Genreation vs. Testing[ Go to top ]
- Posted by: Dirk Ludwig
- Posted on: June 23 2006 09:36 EDT
- in response to Casual Visitor
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 -
Re: Article: Testing a persistent domain model[ Go to top ]
- Posted by: Race Condition
- Posted on: June 23 2006 09:43 EDT
- in response to Regina Lynch
...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!