Hi Ken,
I moved the discussion to a new topic as the old one was hijacked.
Using labels is a good idea to solve a class of problems one would
encounter. All those places where you can navigate from an entity to
another starting from a label. (Without a predicate as this would be
some knowledge about the test data again.)
I'm not to concerned with redundancy in test data file. This would be
okay with me. I think one has to balance the redundancy and
readability. If you can have a better readability of a tests for a bit
more redundancy that is a trade-off I might consider.
country:
? name: $label
- [Canada] country_id: 1
is to hard to read for my taste.
Generating ids with the framework is actually just the first step.
There could be a derived data that has to be stored in the database.
Besides the ids problem you solved the derived data in the database
fixtures is clearly a pain point using dbunit.
I think, your ideas can remove most of the redundancy in the data
files, but the underlying problem is that one still has to have
knowledge about the fixture in the test. (Unless you build a query
feature on top that is as capable as the data access layer you would
like to test with it. But then the queries would be redundant.)
The initial example is still the easiest:
jdbcTemplate.queryForInt("select count(*) from two_string_table")
should equal (2)
How do you know that you have exactly 2 values in your table unless
you hard code it? This is of course a simple example one can come up
with arbitrarily complex ones. For example you can start by defining a
predicate that partitions the set of entries.
Thomas
On 23 Okt., 17:19, Ken Egervari <[email protected]> wrote:
> Yes, I do (hopefully).
>
> It's not implemented yet, but it's next on the list, and it shouldn't
> be too difficult. Perhaps I'll run the idea by you and you can let me
> know if this fixes it for you.
>
> The framework already has a way to specify labels, so you can label a
> record like this:
>
> country:
> - [Canada] country_id: 1, name: "Canada"
> - [United States] country_id: 2, name: "United States"
>
> Of course, there's some redundancy there, so you can pass in an
> expression to the name property like this:
>
> country:
> - [Canada] country_id: 1, name: $label
> - [United States] country_id: 2, name: $label
>
> That gets rid of the duplication in text whenever it's needed, but we
> still have the duplication where name=$label, so we can use default
> values to refactor that.
>
> country:
> ? name: $label
> - [Canada] country_id: 1
> - [United States] country_id: 2
>
> So far, everything has been implemented as shown. The next steps have
> not, but will be.
>
> I agree that ids are a messy way to reference data that leaves a lot
> to be desired. One thing we can do is get the framework to generate
> the ids... that way we can access the rows from labels instead:
>
> country: [pk: country_id]
> ? name: $label
> - [Canada]
> - [United States]
>
> This doesn't work for pk's consisting for of two or more columns, but
> it's going to work in 99% of cases where you are pulling a root object
> that is needed for test against.
>
> Now, one thing I've left out is a name space for the label. It's
> implied because of the table name. The reason it's important for
> references later. The syntax could look something like this:
>
> province: [pk: province_id]
> - name: $label
> - [Ontario] province_id: $country(Canada)
> - [New York] province_id: $country(United States)
>
> I haven't really decided yet yet to put these in quotes or notes. I'll
> have to see what feels natural and looks best. Maybe this looks
> better?:
>
> province: [pk: province_id]
> - name: $label
> - ["Ontario"] province_id: $country("Canada")
> - ["New York"] province_id: $country("United States")
>
> Anyway, in your test code, you could do something like this:
>
> val province = provinceDao.find( "Ontario".toId )
>
> "toId" could be an implicit that maps Strings (or Symbols I guess) to
> a wrapper that has a toId() method. The implicit will return the same
> id that the framework generated when it parsed in all the test data.
>
> Does this approach solve the problem? Suggestions/improvements?
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
