Currently what I did is combine ItemListSpecs with another test, so I gave it a 
more generic name than ItemsList, hence MapperSpecs2. The idea is that some 
tests really have zero to do with the vendor, but higher-level behavior. 
H2MemoryProvider is incidental--in memory databases are perfect for testing. So 
I'd prefer not putting the choice of testing db in the name of a 
driver-independent test.
If an ORM is a form of caching then these are cache-related specs.
If David vetoes the change on RB, a name is irrelevant; and depending on his 
proposal it may be temporary; but I'm looking for a name that says "More Mapper 
Specs except these specs are run on one arbitrary driver rather than on all of 
them, because these specs are driver-independent by definition."
Thanks!

-------------------------------------
Jim Barrows<[email protected]> wrote:

On Mon, Mar 8, 2010 at 1:00 PM, Naftoli Gugenheim <[email protected]>wrote:

> I'm not 100% clear on your proposal.
> First of all, is what I've done (on RB) in the meantime okay (without a
> ticket)? Basically, I renamed ItemsListSpecs to MapperSpecs2 and put the
> test for issue 370 there. MapperSpecs2 only uses H2 memory db. (Any
> suggestions for a better name?)
>

ItemsListOnH2MemorySpecs.scala
ItemsListH2MemorySpecs.scala
ItemsList_H2Memory_Specs.scala -- this is probably the most readable and
sets up the pattern for names like
WhatsUnderTest_JDBCDriverSpecificName_Specs

It's wordy, but if you want everything in the same directory, then that's
what happens.  Probably better would be:

itemsList/ItemsListSpecs.scala
itemsList/H2MemorySpecs.scala
itemsList/JdbcDriverSpecs.scala

Less wordy, but you have one more directory to traverse to get there.
 However if you figure we'll have mysql, sqlserver, oracle, h2 & postgres at
a minimum, I think that this actually easier on the eyes when trying to find
the right jdbc driver specific tests.  In addition, we'll probably at some
point end up with version specific test cases as well.  That should probably
go in the same file, and use the version as part of the name.

So the specs name (ItemsList, in this case) is the cross driver tests, with
the driver specific specs test in the same directory.


Any other ideas?




> As for your proposal, are you saying that things like ItemsListSpecs and
> 370, which deal with high-level Mapper API not directly related to the
> database, should ideally be testable on every database vendor? And/or are
> you saying that *all* the tests should be run by default on only one driver
> but have the option to run on all?
> Also, is it possible to run MapperSpecs for all the drivers in parallel,
> and if so would that cause it to finish faster?
>
> Thanks.
>
> -------------------------------------
> David Pollak<[email protected]> wrote:
>
> On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim <[email protected]
> >wrote:
>
> > Based on discussion on Review Board item 247, I want to propose the
> > following change to the organization of Mapper specs.
> > Currently there are four files in
> > framework/lift-persistence/lift-mapper/src/test/scala/net/liftweb/mapper:
> > DBProviders - initalization for each provider to be tested
> > MapperSpecs - the original set of tests. Tested per provider, which makes
> > sense for tests that interact with the database
> > ManyToManySpecs - tests I added with an enhancement to ManyToMany to not
> > choke on broken joins. Only uses DBProviders.H2MemoryProvider. When FK
> > constraints are enabled in H2 this will have to disable them.
> > ItemsListSpecs - tests for a bugfix in ItemsList. Also only uses
> > DBProviders.H2MemoryProvider.
> >
> > Currently MapperSpecs takes about five minutes to run on my laptop. So
> any
> > new test that isn't driver dependent should probably not be tested on all
> > drivers. Thus I'm considering consolidating ItemsListSpecs and
> > ManyToManySpecs into one specs for all H2MemoryProvider-only tests.
> > Then, with two set of tests, one run for each driver and one not, maybe
> > their names should reflect that.
> > It's just a possible idea, but what do people think? Also, if I would go
> > ahead would it need a ticket or just straight to RB?
> >
>
> I agree with the goal of shortening the time it takes to run mapper tests.
>
> I would like there to be a way (not the default, but something that can be
> done with some form of compiler/maven flags) to run all cross-products of
> all tests so we just make 100% sure that things work on all RDBMSs.
>
> Please open a ticket first before putting stuff on RB.
>
>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<liftweb%[email protected]>
> <liftweb%[email protected]<liftweb%[email protected]>
> >
> > .
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
> >
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<liftweb%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<liftweb%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" 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/liftweb?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" 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/liftweb?hl=en.

Reply via email to