Identify weak points in MetaCG tests

[pearzt]

This issue is intended to serve as a list of MetaCG features and intricacies for which we should improve the testing coverage in the graphlib's tests.

[pearzt]

@jplehr During today's meeting, we agreed that it's a good idea to make sure that we don't rely on the tests in PGIS to cover all of MetaCG's features. Following up on your comment here, could I ask you to start creating a list of specific MetaCG features and intricacies that are currently covered only by the PGIS tests? We could then use this thread a starting point that any one of us can extend or pick up by adding better tests.

[jplehr]

I don't have a specific list. My comment targets that in our unit tests, focus on single specific things, as they should. However, when we remove PGIS, we no longer have any consumer of the library in-tree.

What I fear then is that we introduce APIs or change things that make reasonable / common use cases more cumbersome. In that regard I would like to see some more integration testing inspired test cases. I would think that this can be done in some nice smaller tools that allow some sort of inspection or querying of the MetaCG.

[pearzt]

We actually briefly discussed a few days ago whether something like cgquery or cgfilter would be useful things to have. Although, at least for me, that's the type of task that pymetacg is intended to solve. Still, I agree that an integration test that checks a full pipeline of operations would be nice, e.g., cgcollector -> cgmerge (-> cgconvert) -> cgquery (or querying via pymetacg).

[jplehr]

I guess the point is: not everybody prefers Python for such tools.
In any case, I would see value in some simple tools, also to just print out some statistics of the graph etc.

IMHO we need to:

• identify "common"/"typical" usages
• identify MetaData we want to support as part of MetaCG.

Implement end-to-end tests for both of them.