Hi Mike, > Is derby entirely in memory or does it have a filesystem footprint?
It does. > I've found that maintaining tests using standalone data files is far more > difficult than using helper classes to create default data sets. Bootique tools support both types of datasets: file- and API-based, e.g. [1]. And fwiw I personally hate both of them :) Andrus [1] https://github.com/bootique/bootique-jdbc/blob/master/bootique-jdbc-test/src/main/java/io/bootique/jdbc/test/Table.java > On May 3, 2018, at 3:26 PM, Mike Kienenberger <[email protected]> wrote: > > As a general observation after using dbunit for 13 years, I've found > that maintaining tests using standalone data files is far more > difficult than using helper classes to create default data sets. I > ended up with far too many data sets, and things were even worse if I > needed a test with many instances of the same entity or tests with > entities in complicated relationships. > > Trying to update the data sets every time the schema changed was > difficult and time consuming. That was with > named-key-value-property xml databases. I would expect csv to be even > more difficult. > > Switching to programically generated data has made life far easier for > me. Schema changes only have to be made one place. I can create > convenience methods that allow me to only specify the fields of > interest rather than every field, as well as create common complex > data relationships with a single call. On more recent projects, I > now generate the default "populate every field" methods for individual > entities. That breaks my convenience methods when the schema changes > and forces me to fix the data generation immediately while it's still > obvious what column has been added or removed. It's been a > life-saver in this project where there are 6 other developers also > modifying the schema in unexpected ways. > > Andrus, > > Is derby entirely in memory or does it have a filesystem footprint? I > remember trying to use it back when I was first looking for in-memory > databases, but something prevented me. It was probably 13 or more > years ago, so it's very likely that whatever was wrong is no longer an > issues. > > > > > On Thu, May 3, 2018 at 3:19 AM, Andrus Adamchik <[email protected]> > wrote: >> I use Derby. From my experience it is the most "serious" choice out of all >> in-memory Java databases. HSQL/H2 left a bad aftertaste from the days when >> we used it for the Modeler preferences. Though this may not be relevant in >> the context of unit tests. >> >> Beyond that, I use bootique-jdbc-test / bootique-cayenne-test to manage DB >> lifecycle, datasets and assertions. There may be a lot of overlap with >> DBUnit, but if you are on Bootique, it integrates very nicely with the >> existing app configs, Cayenne models, etc. It supports loading data from >> CSVs, comparing DB state with CSV, referencing tables by mapped Cayenne >> classes, etc. There not much documentation as of yet, but here is a small >> random example: >> >> @ClassRule >> public static BQTestFactory TEST_FACTORY = new BQTestFactory(); >> private static CayenneTestDataManager DATA_MANAGER; >> >> @BeforeClass >> public static void beforeClass() { >> BQRuntime app = TEST_FACTORY >> .app("-s", "-c", "classpath:config.yml") >> .autoLoadModules() >> .createRuntime(); >> >> app.run(); >> >> DATA_MANAGER = CayenneTestDataManager.builder(app) >> .doNotDeleteData() >> .entitiesAndDependencies(E1.class, E2.class, E3.class) >> .build(); >> >> >> DATA_MANAGER.getTable(E1.class).csvDataSet().load("classpath:e1.csv").persist(); >> } >> >> @Test >> public void testXyz() { >> // send some requests; check the data in DB... >> >> Table e1 = DATA_MANAGER.getTable(E1.class); >> e1.matcher().assertMatches(4); >> } >> >> Andrus >> >>> On May 2, 2018, at 10:59 PM, Ken Anderson <[email protected]> >>> wrote: >>> >>> All, >>> >>> We’re thinking about setting up an in-memory database in place of SQL >>> Server for doing unit tests. Does anyone have any experience doing this >>> with Cayenne? Any recommendations or warnings? >>> >>> Thanks, >>> Ken >>
