Bug #72136
openMake Validator Unit Tests behave like they are used from Domain Model
0%
Description
There is a big problem with Extbase validator unit tests found in #72047: They don't work the way the domain model works.
If not all options are given in an extbase domain model the given options are MERGED with the default options from the validator supplied in $supportedOptions
.
In the validator unit tests the options are just plainly set and NOT MERGED with the default options.
This can lead to differences in the handling and in case of #72047 lead to completely ignoring the given options and only using the default options from $supportedOptions
Updated by Susanne Moog about 7 years ago
- Status changed from New to Needs Feedback
Two questions / remarks here:
- Can you add an example to this ticket about what exactly do you mean?
- If we would add some kind of simulation of the behaviour extbase does internally with merging options before calling methods, wouldn't we then have functional tests? As far as I can see the unit tests are ok, but what is actually missing are the functionals than test including the merge of options.
Updated by Stephan Großberndt almost 7 years ago
Phew.. two years later.. if I remember correctly its like this:
In extbase you have supportedOptions defined in a Validator
protected $supportedOptions = array( 'minimum' => array(0, 'The minimum value to accept', 'integer'), 'maximum' => array(PHP_INT_MAX, 'The maximum value to accept', 'integer'), 'startRange' => array(0, 'The minimum value to accept', 'integer'), 'endRange' => array(PHP_INT_MAX, 'The maximum value to accept', 'integer') );
If you do not provide all supportedOptions in your validate annotation like here
* @validate NumberRange (endRange = 2)
(minimum, maximum and startRange not provided) all is well in Extbase itself as the supportedOptions will get merged with your given annotation in
$this->options
- but in the current tests for this (which are apparently (only?) Unit Tests)
$this->options
only contains the values from the annotation (so minimum, maximum and startRange would be missing here).
Whether the correct way to test/solve this is to use functionals instead I can't say - I bet you can ;-)
I found this issue when searching for the bug in #72047 and I was wondering why (although this area is covered) the tests did not find the issue of the no longer working startRange/endRange annotation (which was fixed separately in https://review.typo3.org/#/c/45109/)
Updated by Alexander Opitz over 6 years ago
- Status changed from Needs Feedback to New