fix: run golden tests with test optimization enabled

[Giuspepe]

Description

This fixes #363.

Currently, golden tests fail when running them with very_good test with test optimization enabled. This is because goldenFileComparator searches for the golden files relative from the currently running test file. With optimization enabled, the golden files are searched from the .test_runner.dart file instead of from the original test files.

The solution I suggest is to use a custom implementation for goldenFileComparator which knows about the implications of the test optimization. It finds the correct absolute path of the golden file by searching for a single file ending with the given relative path from the test base directory. For further details, see my comment here: #363 (comment)

This approach fails in the following situation:

• test file test/a/foo_test.dart uses the relative path goldens/foo.png to refer to the golden image at test/a/goldens/foo.png
• test file test/b/foo_test.dart uses the same relative path goldens/foo.png to refer to the golden image at test/b/goldens/foo.png

In that case, searching for files ending with the path goldens/foo.png does not return a single result but two possible results. An exception will be thrown in that case. I think this is ok because it is a rather theoretical edge case and this approach solves all realistic cases.

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[Giuspepe]

@felangel would you mind reviewing this? Thanks!

[wolfenrain]

Thank you for your contribution!

Our bundles come from an internal brick repository currently, so we normally supply the change there and then do a PR here. But I will merge this as-is so we don't lose your contribution, as soon as the CI succeeds!

Just for your information, I'll supply some extra changes from our internal bricks in a separate PR to keep it up to date with that repo. In case you see another PR today that changes your code ;-), it wont change any of the functionality that your provided.

Once again thanks for this PR!