I guess it depends on the situation. API-based is easier to comprehend and manage on the lower end (small/narrow data sets), while CSV scales much better to long/wide datasets. I often generate the later with real SQL against a real DB, then edit in LibreOffice/Excel, then save as a CSV in the project.
Andrus > On May 3, 2018, at 3:35 PM, Ken Anderson <k...@anderhome.com> wrote: > > Which do you late less? :) > >> On May 3, 2018, at 8:32 AM, Andrus Adamchik <and...@objectstyle.org> wrote: >> >> 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 <mkien...@gmail.com> 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 <and...@objectstyle.org> >>> 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 <ken.ander...@amphorainc.com> >>>>> 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 >>>> >> >
