[tests-only] Refactor test code

[phil-davis]

On top of PR #4

I did: 1) adjust composer.json to the latest tool dependency versions, and composer update to get a really up-to-date composer.lock 2) change PHPUnit_Framework_TestCase to PHPUnit\Framework\TestCase (that is what PHPunit8 really uses) 3) add to .gitignore 4) adjust FeatureContext for not-needed things and other minor edits 5) add some parameter types in tests - "the modern way"

The tests pass locally:

make test
...
108 scenarios (108 passed)
683 steps (683 passed)
0m0.59s (9.28Mb)

$ ./vendor/bin/phpunit -c tests/unit/phpunit.xml 
PHPUnit 8.5.13 by Sebastian Bergmann and contributors.

......................................................            54 / 54 (100%)

Time: 88 ms, Memory: 6.00 MB

OK (54 tests, 77 assertions)

[phil-davis]

Note: the tests do not run in drone CI. ~Should we be adding those to CI?~ - done

[phil-davis]

https://drone.owncloud.com/owncloud/owncloud-updater-server/21/1/2

vendor/bin/phpunit -c tests/unit/phpunit.xml
PHPUnit 8.5.13 by Sebastian Bergmann and contributors.

......................................................            54 / 54 (100%)

Time: 61 ms, Memory: 6.00 MB

OK (54 tests, 77 assertions)

PHP unit tests pass in CI.

[phil-davis]

https://drone.owncloud.com/owncloud/owncloud-updater-server/22/2/2

108 scenarios (108 passed)
683 steps (683 passed)
0m0.78s (8.59Mb)

behat integration tests pass in CI.

[xoxys]

I still don't really understand why. oC10 for example has maybe a test for the config.php but whatever a customer set on its own deployment is not tested. Why do we need to test every configuration value?

[VicDeo]

@xoxys because we always should be 100% sure that upgrade path is not broken in the middle - it is possible to start with for example 10.1 and end up with 10.5 (or 10.6+ once it is released) That's why we have integration tests split by channels for any release. It helps not to recheck whether the whole upgrade path has been not broken unintentionally.