Re: [Lift] Reorganize mapper specs?
On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Reorganize mapper specs?
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?) 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 Pollakfeeder.of.the.be...@gmail.com wrote: On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Reorganize mapper specs?
On Mar 8, 2010, at 3:00 PM, Naftoli Gugenheim 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?) H2DatabaseMapperSpecs? 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 Pollakfeeder.of.the.be...@gmail.com wrote: On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Reorganize mapper specs?
On Mon, Mar 8, 2010 at 1:00 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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 Pollakfeeder.of.the.be...@gmail.com wrote: On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.com 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at
Re: [Lift] Reorganize mapper specs?
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 Barrowsjim.barr...@gmail.com wrote: On Mon, Mar 8, 2010 at 1:00 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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 Pollakfeeder.of.the.be...@gmail.com wrote: On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.com 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply
Re: [Lift] Reorganize mapper specs?
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 Barrowsjim.barr...@gmail.com wrote: On Mon, Mar 8, 2010 at 1:00 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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 Pollakfeeder.of.the.be...@gmail.com wrote: On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.com 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com .
Re: [Lift] Reorganize mapper specs?
On Mon, Mar 8, 2010 at 1:59 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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. I'm curious how my naming proposal doesn't do that? In a much more structured way? -- 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Reorganize mapper specs?
Not sure -- it sounded like you were describing a scenario with separate test files for each combination of area being tested and driver, where I was describing combining multiple areas in one file (like MapperSpecs is now). Maybe I misunderstood. - Jim Barrowsjim.barr...@gmail.com wrote: On Mon, Mar 8, 2010 at 1:59 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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. I'm curious how my naming proposal doesn't do that? In a much more structured way? -- 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Reorganize mapper specs?
On Mon, Mar 8, 2010 at 2:16 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: Not sure -- it sounded like you were describing a scenario with separate test files for each combination of area being tested and driver, where I was describing combining multiple areas in one file (like MapperSpecs is now). Maybe I misunderstood. Both can go into one file. The second one would have a file name of ItemUnderTest.scala while each separate specs test could still follow the driver specific naming convention. The one that tests things that shouldn't care about driver would be called ItemUnderTestSpecs. - Jim Barrowsjim.barr...@gmail.com wrote: On Mon, Mar 8, 2010 at 1:59 PM, Naftoli Gugenheim naftoli...@gmail.com 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. I'm curious how my naming proposal doesn't do that? In a much more structured way? -- 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Reorganize mapper specs?
On Mon, Mar 8, 2010 at 12:00 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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)? What part of Please open a ticket first before putting stuff on RB. is unclear? You've consumed all of my time for stuff related to you until April. 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?) 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 Pollakfeeder.of.the.be...@gmail.com wrote: On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim naftoli...@gmail.com 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
