#75 Enhance Fermenter for easier generation resource unit testing

[jaebchoi]

Description
Adopting projects have reported that testing generation artifacts is complex. Implementors usually favor manual steps while recognizing that this is a non-optimal approach. For instance, the most common approach is running a project's entire plugin to see if the desired outputs are created appropriately.

This ticket should provide an initial increment of functionality that lowers the bar for unit testing generation resources. If we can make this process very easy, it will incentivize projects to push more of their testing testing effort "left" into unit tests.

This issue is tracking #75

[jaebchoi]

I: Seems like following profile referenced entities doesn't even get added nor used as part of dereferencing.
protected Map<String, ExpandedProfile> includes = new HashMap<>();

public void addReferencedProfile(ExpandedProfile profile) {
    includes.put(profile.getName(), profile);
}

Added logic to fix as this is needed for unit testing.

[epwilkins]

I'm a little confused how this meets the needs of #75. That ticket talks about providing test-friendly and/or test-specific APIs to ease testing in projects consuming Fermenter. It seems like this is just tests within Fermenter itself. The only change that would impact consumers would be ExpandedProfile fix, but I can't connect the dots on how that eases testing.

Can you explain a bit about what you're going for in this PR?

[jaebchoi]

@ewilkins-csi Yup!
From what I understood, the intention of this unit test is to provide consumers of fermenters to make sure they have correct configuration of profiles.json and targets.json. i.e. if consumer specified xyz template files, we make sure there’s xyz template file exists in the codebase and so forth.

My test cases are example of how configuration testing can be done and consumers can implement those unit tests with changing parameters.

Fermenter’s unit test as defined here have a goal that fermenter can function as expected.

My testing’s goal is to provide user that this is what their intention for configuring json files (profiles and target) so that they expect to have correct artifacts generated.

Does that make sense?

maybe I might have made this bit complicated for consumers or had wrong direction?
Im open to ideas!

[epwilkins]

Following up on the conversation above. We had a conversation offline about how this will meet the needs outlined in the ticket. Discussed pulling some of the example logic in the unit tests (e.g. for loading profiles/targets, making assertions about profiles) into an actual test utility class that could be directly used by consumers rather than just copying the example code completey.

[epwilkins]

Q/S: Could this just be done as part of readProfiles?

[jaebchoi]

dereference needs both ProfileMap and TargetMap to be loaded, so Ill have another method readProfileAndTarget and add dereference there and return Pair to return both profileMap and TargetMap.

Def will add javadoc to explain