There is one place I always use files, and that's for constants and
lookup tables. Data that almost never changes. My database test
framework always pulls in and populates these for me, so I never have
to think about them. I generally import these directly from
production.
For data that changes, the API-based approach is a winner for every
situation. I still have ancient tests using files, and every once in
a while when such a test fails, I clean it up. I can generally
replace an entire file with a couple of lines of code at this point.
However, there is a reality that your testing code can get more
complicated than your code-to-be-tested if you are not careful.
That's why generating the basic entity-spawning methods helps so much.
And there's always the danger that one of your unimportant default
column values will suddenly become important, and that could force you
to have to fix a lot of convenience methods. Eclipse method
refactoring makes that easy, though.
But I still cringe thinking of how I'd deal with updating one of
Andrus's big cvs data sets. I guess you'd need to reload it into a
database, make changes, and then export it again?
pseudocode for how I typically do things now:
{
Dataset dataset = new DataSet();
// defaults to creating active accounts, and we won't have easy access
to those account ids
long userId = dbunit.createUserWithManyAccounts(dataset, username,
number-of-accounts-to-create);
long closedAccountId = dbunit.createAccount(dataset, Status.closed);
dbunit.addAdditionalAccountToUser(dataset, userId, accountId);
dbunit.commit(dataset, REFRESH-MODE);
}
public createAccount(Dataset dataset, Status status) {
int unimportant1 = 0;
String unimportant2 = "default";
String unimportant3 = null;
// etc
// generated method
return createAccountFully(dataset, unimportant1, unimportant2,
status, unimportant3);
}
On Thu, May 3, 2018 at 8:35 AM, Ken Anderson <[email protected]> wrote:
> Which do you late less? :)
>
>> On May 3, 2018, at 8:32 AM, Andrus Adamchik <[email protected]> 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 <[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
>>>>
>>
>
