Adds Pest support #136
Merged
Adds Pest support #136
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been running into some issues when attempting to use the Better PHPUnit and Better Pest plugins at the same time. Tests are taking ~5 seconds to start.
I did some digging and it appears something has changed in VS Code which triggers both plugins to activate when running either command (e.g.
better-phpunit.runorbetter-pest.run).I used my best Sherlock skills, but was not able to determine what VS Code was doing under the hood to trigger it.
So instead, I thought...
"Why not just add support for Pest to Better PHPUnit - that way I only need one plugin and the issue is resolved."
My idea here was to read the
composer.jsonand ifpestphp/pestis present, use thepestbinary, otherwise, use thephpunitbinary.The actual execution was pretty simple:
However, it turns out VS Code have completely rewritten the way tests work and so I had to go through the process of migrating from the vscode module to @vscode/test-electron.
This also meant targeting a new version of VS Code. I'm not sure whether this has any impact for existing users? I assume it could be if their installation of VS Code is outdated. Wondering if maybe it warrants a new major version should this get merged.
Seeing as I went to the effort of migrating the tests, I figured I may as well also get them running in CI.
To run the tests locally should be a case of
npm install && npm run test.So that's the story of how PR with 2 file changes became a PR with 17 file changes... Sorry!