Improve tests, replace psr7 implementation

[acasademont]

Trying to add tests for #144 proved to be quite complicated if we don't have a full Symfony kernel for the tests. Therefore, I've refactored all the current tests to stop using mocks and use a real Symfony kernel/controllers...

As a side effect, the current PSR-7 library did not support the UploadFileInterface and replace it with Guzzle (which is better maintained by the way).

This is just the first step in all the planned refactors :)

[acasademont]

Dropped 2.X already

[andig]

What do you think- can we release this in a point release? Effectively we're dropping support for Symfony before 3.4?

[acasademont]

The proposed 'kernel.reset' interface for Symfony is only in 3.4+. Also, SF 2.x is EOL already, I'd say it's time to move on.

[andig]

Wow, this is huge! Will need some time to check, sorry.

[acasademont]

No worries, happy to help! The test assertions haven't changed, seems big but I don't think is thaaat big :p

[acasademont]

@andig basically I copied all the code in the previous Kernel mock and put it inside the newly created controllers, that allows us to keep the assertions the same

[acasademont]

This is used to have support for the register_file function without having a real Slave

[acasademont]

will be useful when creating a test that checks if a symfony container resource is actually being added to the list of watched files

[andig]

I guess that's not really needed here but it reduces the number of dependencies?

[acasademont]

This is just a change to a more complete PSR7 implementation and to a better maintained library, it doesn't really change the number of dependencies itself.

Also, the Psr7 Response object is used here. Are you refering to something else?

[andig]

What do you think- can we release this in a point release? Effectively we're dropping support for Symfony before 3.4?

[andig]

Do we need to require the annotations here or aren't they implicit?

[acasademont]

Nopes, they aren't implicit, Symfony relies on them for routing annotation but you need to import the library yourself

[andig]

As for symfony bundle: is it a good idea to require them in the composer json? That way we will only ever be able to install a single framework instead of testing them separately. Wondering if it would make more sense to move the symfony framework to travis.yml to prepare a separate environment per framework.

Apart from that LGTM.

[acasademont]

As for symfony bundle: is it a good idea to require them in the composer json? That way we will only ever be able to install a single framework instead of testing them separately. Wondering if it would make more sense to move the symfony framework to travis.yml to prepare a separate environment per framework.

It's a good question! The three frameworks can live together without a problem, we're already doing that for phpstan in travis (we install Laravel, Symfony and Drupal). I'm not a Laravel or Drupal expert but I don't see why testing them should interfere with Symfony.

Also, I'm not a fan of moving too much logic into Travis, imo tests should be runnable with a simple "phpunit" command.

[andig]

Then I would propose to merge as-is and then proceed with #144

[acasademont]

@andig sounds good to me! I will submit another PR before #144 that adds new tests for all the hacks we have in place and then check if the tests still pass after the refactor.