We have cases in which app developers forget to delete user data when a user is being deleted. This could be problematic as future users with the same username could then access this data.
This mitigates this risk a bit by not allowing reusing of usernames. That said, we still need to fix occurrences of these issues by deleting missed data.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
[Jest](https://jestjs.io/) is a test runner that focuses on simplicity.
It instruments babel to transform modules and test them.
Using Jest simplifies the existing configuration and allows dropping a
bunch of workarounds, as well as following the shared Babel
configuration for new code.
Signed-off-by: François Freitag <mail@franek.fr>
- extends IAccountProperty for verificationData getters and setters
- implementation thereof ^
- and of course adaption of UsersController
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
2) Test\Support\Subscription\RegistryTest::testDelegateIsHardUserLimitReachedWithoutSupportAppAndUserCount with data set #0 (35, 15, 2, false)
Cannot stub or mock class or interface "Test\Support\Subscription\UserInterface" which does not exist
3) Test\Support\Subscription\RegistryTest::testDelegateIsHardUserLimitReachedWithoutSupportAppAndUserCount with data set #1 (35, 45, 15, false)
Cannot stub or mock class or interface "Test\Support\Subscription\UserInterface" which does not exist
4) Test\Support\Subscription\RegistryTest::testDelegateIsHardUserLimitReachedWithoutSupportAppAndUserCount with data set #2 (35, 45, 5, true)
Cannot stub or mock class or interface "Test\Support\Subscription\UserInterface" which does not exist
5) Test\Support\Subscription\RegistryTest::testDelegateIsHardUserLimitReachedWithoutSupportAppAndUserCount with data set #3 (35, 45, 55, false)
Cannot stub or mock class or interface "Test\Support\Subscription\UserInterface" which does not exist
Had to use the Database user backend, as using multiple interfaces is deprecated:
https://github.com/sebastianbergmann/phpunit/issues/3955
> This functionality should be deprecated as "having to use it" is almost always a symptom of bad design.
> More importantly, though, the support for the creation of test doubles that implement multiple interfaces
> resulted in code that is hard to maintain.
Signed-off-by: Joas Schilling <coding@schilljs.com>
In the WebDriver protocol, when a command fails because it can not
interact with the target element, an "element not interactable" error is
generated. It can be a transitive issue (for example, due to an
animation), so when the error is received the command should be tried
again, just like done, for example, with "ElementNotVisible" exceptions.
However, the last version of the "instaclick/php-webdriver" library
compatible with the Selenium Driver of Mink did not support yet that
WebDriver error. And even if Chrome is run using the old protocol an
unknown "element not interactable" error can be received anyway in some
cases. When an unknown error is received by the
"instaclick/php-webdriver" library it is thrown as a generic Exception
so, until the library can be updated, the message of generic exceptions
is checked and the command is retried if it matched.
For the time being "element not interactable" errors are handled like
"ElementNotVisible" exceptions; this may need to change once the error
is better understood.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>