A base end-to-end test for mummifiers.

Description

Mummifiers need a framework for testing conversion of actual files. This would involve at the least taking an existing file in a source directory and producing output in a target directory. Because it involves copying files, it should probably be classified as an integration test and run separately. This will help with some of the testing needed in GUISE-126.

The current idea is to have a base test that sets up a project as in MarkdownPageMummifierTest for example.

  • It would use the JUnit 5 @TempDir extension to set up temporary source and target directories.

  • It would allow subclasses to provide files or directories to use to populate the source directory.

  • It would allow subclasses to specify certain configuration values to override the defaults.

Once this is put in place, the most basic tests for OpaqueFileMummifier can be added, for example, to show that the file was copied and has identical content.

Environment

None

Activity

Show:
Garret Wilson
November 21, 2020, 11:43 PM

Because the LifeCyclePhase.INITIALIZE phase always happens (and must happen to initialize things), but because how initialization happens depends on the how things are kicked off (here from the CLI), we should probably have a separate GuiseMummy method that one could call if initialization has already happened.

After getting back deep into this code, I'm not so sure about this. Part of the thing that initialization does is checks to see if there is a .guise-mummy.* configuration file in the site source directory. We could find a way to keep this from occurring, but why? Why is loading this config file any less part of the mummificiation than mummifying an actual file (which may also load e.g. sidecars and other config files.)

Creation of the project allows designation of a configuration file; this should be sufficient for tests. maybe we should just leave the original mummify(@Nonnull final GuiseProject project, @Nonnull final LifeCyclePhase phase) form and let it do what it's going to do.

I think one of the original goals was to get rid of the getDirectory() from the project, to remove file system references from the project level. This would be a step toward removing references to the file system from the entire infrastructure, using some plugin module for requesting content and working with paths. But we're a long ways from that, and it's not clear how yet how we would do that so we don't even know what we want at this stage. I think for the moment just leaving it like it is and allowing the integration tests to configure the project is good enough, since they will still need to configure some file system anyway.

Fixed
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Garret Wilson

Reporter

Garret Wilson