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
>
