DriverIndependentSpecs? -Ross
On Mar 8, 2010, at 3:59 PM, Naftoli Gugenheim wrote: > 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. > -- 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.
