Page 1 of 1

Choosing a PHPUnit version

PostPosted: July 31st, 2018, 2:26 pm
by emsmith
The bundled PHPUnit version is REALLY really old

As in no longer supported old

We currently have to do some rather terrible workarounds every time the devsense php visual studio extension updates to get our unit tests working inside visual studio again

1. Try to run the unit tests
2. Get a failure
3. Copy the file path of the extension location
4. Open that location and copy a corrected version of PhpTestingPrinter.php for newer versions of phpunit (basically changes for namespaces)
5. Download an up to date phar of phpunit, rename it to phpunit-5.7.9.phar and copy it over the existing phar

Run tests successfully!

But it would be FAR easier to just allow the user to point to their own phpunit phar if they want, like you can choose your own php install

Also you REALLY should update your phpunit that is the default bundle to at least a supported version!

Support ended for version 5 of phpUnit in February - https://phpunit.de/
Support will ends for version 6 of phpUnit February 1, 2019

We're using phpunit version 7 and will be upgrading to version 8 when it's ready so 5 is simply not even usable for us.

Re: Choosing a PHPUnit version

PostPosted: August 6th, 2018, 9:00 am
by Miloslav Beno
Hello,

Thank you for great feedback.

Our bundled phpunit version is this old, because it works accros all the php versions people can choose from. But we will consider updated phpunit bundle as an default for newever php versions.

We do have an ability to use a custom phpunit. Our mistake is we do not have it in the documentation; we will add that asap. For now please take a look at this blog post https://blog.devsense.com/en/2017/06/unit-testing#custom-phpunit and let us know if that works for you.

Thanks,

Re: Choosing a PHPUnit version

PostPosted: August 21st, 2018, 4:39 pm
by emsmith
I really don't want to install phpunit as a dependency in my project (not even as a require-dev item) - because then the library is published to IIS using the visual studio publishing

Not only is that wasteful but pushing dev tools onto a production server is a security risk.

Also I have a phpunit installed globally with composer (along with other tools) and that's not picked up or used

Also I really don't need a phpunit installed for all 15 projects. Instead I have one global install... and one phar

Guess I'll just keep doing it the hard way

Thanks

Re: Choosing a PHPUnit version

PostPosted: August 22nd, 2018, 2:58 pm
by Miloslav Beno
Hi,

Thanks for great feedback.

I agree that phpunit shouldn't go to production. I wonder if we could alter VS publishing for IIS not to include require-dev.

Anyway you got the point with having just one phpunit globally. Please, let us discuss it and we will get back to you.

Thanks,

Re: Choosing a PHPUnit version

PostPosted: August 23rd, 2018, 1:30 pm
by AndyM84
It's a shame you don't just use a composer.json file somewhere to control things like this. Then it'd be easy to also override it with a user setting.

Re: Choosing a PHPUnit version

PostPosted: August 26th, 2018, 12:59 pm
by Jakub Misek
just to summarize this:
- we shouldn't publish dev dependencies
- builtin phpunit is just for quick test & go scenario, although we should update it to the most recent version
- in general every PHP project should require its own phpunit as dev dependency

@AndyM84 a global composer.json is a non-standard approach in VS platform. We should use VS's settings storage in order to make settings properly manageable by VS and its sync & backup features.