The "stash" lock was used to shove .gitignore'd files under the rug
so that they would not interfere with a pure copy of the app.
Vendor files may be ignored in the app, so for performance, the
"stash" lock has been deactivated. Vendor files no longer need to
be downloaded each time the test runs.
The "commit" lock now includes all ignored files so that tests
are run with the files as they are.
e_shortcode_parser normally doesn't need reloading in an e107
installation because installing the "banner" plugin and parsing
shortcodes have always been two separate script calls (page loads).
It would slow down the e107 core to add an e_shortcode_parser reloader
after installing a plugin when the page would later exit without
parsing any shortcodes.
Other tests have been meddling with the e107::wysiwyg() global state
e_parseTest::testToForm() now considers two outcomes of the
e107::wysiwyg() state.
Added a guard to GitPreparer::unsetVcsInProgress() to prevent doing a
`git reset` when there are no test locks present.
Otherwise, the uncommitted changes in the app will be removed by the
shutdown feature introduced in 952c6e5890daa36236be675d8c4f21cecabc1fe7.
Fixed irreversible data loss bug when preparing the app path repo
for tests
OLD BEHAVIOR
Remove untracked files from the working tree before and after
every test suite. The intention was to remove files that could
have been created by the tests, but this also removes all other
untracked files, including third-party plugins and themes.
NEW BEHAVIOR
There is now a triple locking mechanism protecting the state of
the app repository before tests are run so that after tests have
run, all file contents are restored to how they were before the
tests have run.
There are three locks, each guarding a different part of the
original repo:
* file
* commit
* stash
When the file lock is present, E107Base knows that any other file,
tracked, untracked, or ignored, was created by the tested code.
The file lock is checked into the commit lock, which saves all
tracked and untracked files in the form of a commit. This way,
uncommitted code can be tested without manually making a commit that
includes the untracked files.
The stash lock saves all ignored files in a Git stash. Ignored files
go in a stash instead of in the commit lock because they can be a
confounding variable affecting the outcome of tests. They are usually
user-configurable only and may not represent tested states.
When the saving is complete, E107Base will have access to tracked and
untracked files but not ignored files. The tests are run in this
configuration.
After each test suite runs, the repo is reset and cleaned to return
the files to the same state they were in before the test suite began.
Then, the locks are undone first by rolling back the commit lock,
which restores the originally uncommitted tracked and untracked
files. Next, the stash lock is popped, restoring the originally
ignored files. Finally, the file lock is removed, signifying that the
repo is back to its original data before the test suite was run.
In case of an ungraceful exit, at least one of the locks would be
left in the repo. The next time E107Base runs, locks are checked, and
if one or more are present, the repo is restored before the locks are
reestablished.
If the `git` command is inoperative, only the file lock is operative
and does nothing more than signify a test that is in progress or has
exited unexpectedly. Data protection is silently unenforced. This can
lead to unexpected tracked, untracked, and ignored file modifications
that will not be rolled back after a test suite has run.
