[Translation] Rework PhpAstExtractor tests organization for future improvements #60854
Conversation
19b3d28 to
2ed841f
Compare
| use Symfony\Component\Translation\Extractor\PhpAstExtractor; | ||
| use Symfony\Component\Translation\MessageCatalogue; | ||
|
|
||
| abstract class AbstractVisitorTest extends TestCase |
There was a problem hiding this comment.
Should be named AbstractVisitorTestCase as PHPUnit 10 has deprecated the fact of having abstract classes matching the class name suffix of tests (which is Test by default, and we use the default), and PHPUnit 11 fails for such case.
| abstract class AbstractVisitorTest extends TestCase | ||
| { | ||
| abstract public function getVisitor(): NodeVisitor; | ||
| abstract public function getResource(): iterable|string; |
There was a problem hiding this comment.
this should have pphdoc for 2 reasons:
- document the return type fully
- explain what this method is about
| use Symfony\Component\Translation\Extractor\Visitor\ConstraintVisitor; | ||
| use Symfony\Component\Translation\MessageCatalogue; | ||
|
|
||
| class ConstraintVisitorTest extends AbstractVisitorTest |
There was a problem hiding this comment.
having to make a new test class for each test looks weird to me.
we might want to have multiple tests running for ConstraintVisitor for instance, which would then require finding names for those test classes (instead of naming test methods like usual) or to merge everything in a single test (which removes any explanation of the intent of the test, and also prevents testing some legacy feature and non-legacy ones separately)
Designing the AbstractVisitorTest testcase in a way supporting a single test does not really matches the common PHPUnit architecture.
You should rather make it define a utility method taking a NodeVisitor and a resource as argument and returning a MessageCatalogue, and let each test class write as many tests it wants using this utility.
| @@ -0,0 +1,72 @@ | |||
| This template is used for translation message extraction tests | |||
There was a problem hiding this comment.
why using a PHP template to cover the case of extracting from form types ? This does not make sense to me.
| @@ -0,0 +1,72 @@ | |||
| This template is used for translation message extraction tests | |||
| <?php | |||
| // @see https://github.com/php-translation/extractor/blob/master/tests/Resources/Php/Symfony/ExplicitLabelType.php | |||
There was a problem hiding this comment.
why a @see targetting an external file (with a URL that won't even stay valid as it reference master which is a mutable reference)
| @@ -0,0 +1,47 @@ | |||
| This template is used for translation message extraction tests | |||
| <?php new TranslatableMessage('translatable single-quoted key'); ?> | |||
There was a problem hiding this comment.
isn't this missing a use statement ?
2ed841f to
23ead95
Compare
| @@ -35,8 +35,7 @@ protected function addMessageToCatalogue(string $message, ?string $domain, int $ | |||
| $domain ??= 'messages'; | |||
| $this->catalogue->set($message, $this->messagePrefix.$message, $domain); | |||
| $metadata = $this->catalogue->getMetadata($message, $domain) ?? []; | |||
| $normalizedFilename = preg_replace('{[\\\\/]+}', '/', $this->file); | |||
| $metadata['sources'][] = $normalizedFilename.':'.$line; | |||
| $metadata['sources'][] = $this->file->getPathname().':'.$line; | |||
There was a problem hiding this comment.
I think this was done so that extracted metadata always use / in paths even when running on Windows (avoiding to change the metadata depending on whether the last dev running the extraction was using Windows or Unix)
There was a problem hiding this comment.
however, this would make sense only if the path was relative to the project root though. Otherwise, the project location on disk also affects the metadata.
In any case, this is a user-visible change that should probably not be hidden in a PR saying it reorganize tests. It might impact projects using those metadata.
This PR is the first in a series that tend to improve PhpAstExtractor (covering more extractions cases, ease test writting for new cases, etc).
I've worked with @Jean-Beru, @Kazadri and @jprivet-dev in the past few weeks on various new cases to increase the number of "locations" from where the extractor can extract translation keys.
As we were working on my own Symfony fork, I'm opening the PR.
But to be honest my colleague @Jean-Beru did the large majority of the work here. Thanks to him 👏!
To avoid a big PR containing multiple new small features, we need to open and hopefully merge this one first to ease the tests writting for next new Visitors.
NB: I'm not sure to qualify or not this PR as New feature?