File upload tests do not clean up after themselves

OK, here's a proof-of-concept patch that adds these things:

• A step "Given the managed file [filename]"
• A managed_file.feature that verifies that the managed file can be seen at admin/content/file
• An AfterScenario hook that deletes files created during the scenario, INCLUDING files uploaded via the UI during widget tests

The code that creates the file is working fine. The deletion code has a problem, which I've worked around in the AfterScenario function.

For some reason, file_delete cannot find the actual file when run from this function. It keeps reporting "The file public://test.txt was not deleted, because it does not exist." If you go to the UI and delete a file uploaded by the Given step, it works OK, deletes both the entity and the file successfully. But in the AfterScenario function, the actual file does not get deleted.

I've checked local permissions (all directories in the tree are world-executable). I've checked that some other functions that use $file->uri work. For example, you can call the PHP function file_get_mimetype on $file->uri and get the right result. But for some reason, PHP and Drupal can't find the file using the URI. So I've added a hacky step to determine the real path of the file by parsing the URI, and unlink it if it still exists after file_delete. Ideally this should be fixed and the hack removed.

I think what's happening is that the managed file uploaded by the contentpage.feature is being deleted twice. The new AfterScenario hook in this patch deletes all managed files affiliated with the current test user regardless of whether they're in use or not. It's set up this way because Fieldable Panels Panes aren't deleted, so any files uploaded with the file or image widget will report themselves as in use.

Then when the AfterScenario hook included in DrupalContext runs, it deletes the content page with the featured image. The featured image field refers to a file that no longer exists, so you get this error.

If we could programmatically delete FPPs in our new AfterScenario hook before the file delete function runs, we wouldn't need to force deletion. See #2402845: Fieldable panel pane data not cleaned up after scenarios.

Our new function gets to the file first. It deletes anything created by the current user regardless of usage. If the included cleanup function got there first, there wouldn't be a problem - the file wasn't created by our custom Given step, so it wasn't added to the $files array, and it wouldn't still be there in the DB to be collected by the generic cleanup function.

If we had an FPP cleanup function, we wouldn't need the generic cleanup function to delete regardless of usage. We could delete the FPPs first and then the files wouldn't be used anywhere.

Maybe generic file cleanup could go into an AfterSuite function?

Generic file cleanup unfortunately can't go into an AfterSuite function, because those run outside of the scenario context and so don't have access to any of the functions or variables we'll need.

I have an approach that's working locally to delete fieldable panel panes whose first revision was created by a current test user. That's one angle, which allows me to remove the TRUE parameter from file_delete. What that leaves behind is files uploaded to the WYSIWYG using the Media button. Hooks run in the opposite order from the order they're registered, so it looks like our added hooks will always run before the hooks included in DrupalContext. So images inserted into WYSIWYG fields in test pages will always have usage records that prevent their deletion when our cleanup function runs.

I'm working on an angle to call file_usage_delete on images referenced by entities owned by the current test user, which will allow the cleanup function to do its magic on them.

This is complicated.

Here's a patch that deletes Fieldable Panels Panes and removes the TRUE parameter from file_delete. It is working locally to clean up files uploaded via the Image and File widgets. It still leaves behind images/videos (and I assume other file types) inserted into WYSIWYG fields on pages created by test users.

Since the patch in #3 was committed, this patch applies on top of it instead of replacing it.

Here's a patch which adds cleaning up files that are created by a test user and inserted using the Media button. Seems to work for images and videos, at least!

The AfterScenario hook fails on the one-time login test - maybe the Given step doesn't add the user to the $users variable?

The one-time login link test failed. Adding the @api tag to the AfterScenario hook that cleans up files should fix it. I'll take a look at that and also the coding standards things you mentioned.

Here's an updated patch. Adding the @api tag to the new AfterScenario hook prevents the one-time login test from failing. (If files or FPPs are added in tests that don't require the API, then they won't be cleaned up. Right now there are no black-box tests that do that.)

I also did some code cleanup on comments and doc blocks.

Local results indicate this patch is successfully cleaning up FPPs added by tests and files/images added by tests.