-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable default for --enforce-time-limit #2085
Comments
I do not understand what you mean by "Currently by default all tests without large or medium annotation are considered as small for the timeout". For a test without a |
I copied the original Bug report. You are right, you changed the behavior in the 4.7. The idea stay the same : Be able to set a default value for untagged tests. |
A default for "untagged tests" makes no sense as no time limit is not (and should not) be enforced for them. |
@sebastianbergmann Sorry for revisiting this old issue and also #1799: Frankly I also really like the idea behind which would allow enabling this test timeout checking for "legacy" projects containing loads of PHPUnit tests with just a single switch also for tests without So it would allow for the defensiveness that I really like in the PHPUnit tool and its IMHO very sane and defensive defaults (e.g. being strict about useless tests)... => May I open a new (duplicate) issue of this one here (or could you re-open this one)? Or would that be insulting/stalking/... ;-) |
@reinholdfuereder I will not implement this myself but I might consider a pull request. |
Thanks for your fast and encouraging answer. Frankly, I cannot exactly say when I will have time for this pull request and especially how long it will take me to be able to understand the existing code and prepare the contribution. However, we could nonetheless try to discuss the requirements and API/usage:
Oh, and I was actually just wondering about:
|
@reinholdfuereder just to confirm I read you correctly, you propose one of the following solutions:
Personally I would prefer the second option as it more obviously puts a limit on legacy (=unmarked, unspecified) tests while leaving explicitly marked As I have recently added a bunch of CLI and XML-config parameters I would be happy to make a pull request for you. Code reference: phpunit/src/Framework/TestResult.php Lines 623 to 645 in 00d26bb
|
@epdenouden I am wondering why you stumbled over this (closed) issue's recent comments so quickly -- big brother ;-) -- but this is actually really great and welcome! Yes (2x): you understood correctly; and I also prefer this option ( @sebastianbergmann What is your opinion/suggestion? |
@reinholdfuereder Well I sleep in the garbage bins around the back, so whenever people start stirring closed tickets I wake up ;-) But no the reason is much simpler. I have subscribed to all alerts for this repository so I can get a better understanding of how it works and what people do with it. |
@epdenouden Firstly, I love your humour! Secondly, thanks a lot for your pull request preparation:
Of course after this has been merged, the PHPUnit documentation (https://github.com/sebastianbergmann/phpunit-documentation-english) will require some updates:
If it helps, I could try to prepare those documentation updates, referencing your final pull request... |
Hello @reinholdfuereder! And yes, having to specify the default value multiple times is not very elegant. Currently the PHPUnit community is discussing what to refactor for later versions of version 7.x and what needs a complete rewrite for version 8. In short, the whole pipeline from user-facing (command line, XML-config) to the internals could use a good powerwash. |
Ad "Invoker" problem:
|
Yeah, I noticed the dependency on installing Invoker. I will add a warning to the CLI when using |
+1 (Two explicit specific/different warnings in case of missing dependencies are an excellent idea!) |
@reinholdfuereder I will figure out what to do with the documentation, as the docs need updating for both 7.2 and newer versions. |
@epdenouden Thanks a lot for your work (the pull request). And also thanks in advance for taking care of the documentation too: frankly, I had not even thought about that being merged into PHPUnit 7.2 too, mostly because it is not a bug fix, but rather an addition/enhancement or new feature? |
@reinholdfuereder Some work of mine has ended up in 7.2, some newer work in 7.3 and I need to add documentation for both still. This feature is not a bug fix, so it will probably be in the Changelog for a 7.3.x minor. I need to do quite a bit of documenting as my PRs have added a few CLI, config and behaviour changes. And no worries, I'm happy to do it. :) |
@sebastianbergmann I've finished pull request #3224 to provide functionality described by @reinholdfuereder |
@epdenouden Thanks a lot for your efforts and your instant/fast implementation!!! There is one small item in the PR that grabbed my attention: The check for |
@reinholdfuereder As a compromise, could you live with an expanded error message that mentions both the module I want to avoid having to add a whole matrix of all variants of (un)availability of modules and their disabled_* states. |
@epdenouden Sorry if I might not understand you correctly: my maybe naive personal order of preferences is (1) not checking So for (1) instead of: If however this (1) is not defensive enough (for you), because it just warns about "disabled for security reasons" and then executes without error without enforcing timeouts, then I can perfectly live with (2), i.e. your compromise. |
@sebastianbergmann Do you mind re-opening this issue based on PR #3224 by @epdenouden? Considering the pending (a) little review and (b) approval by you maybe presumably targetting PHPUnit 7.4? |
@reinholdfuereder The pull request has made into into |
This is excellent news! And congrats! (Sorry for the delay of my response) |
Currently by default all tests without large or medium annotation are considered as small for the timeout.Currently by default, all tests without a tag among small/medium/large are not considered limited at all and do not fall into the time limitation set for those tags.
I would like to either configure a custom timelimit for them, or at least a configurable default behavoir so I can say all tests are large by default so i can only define some specific ones as small (Or the other way around to be more strict)
Thanks @Flyingmana for the original issue : #1799
The text was updated successfully, but these errors were encountered: