Skip to content
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

Add timeout config parameter #2026

Merged

Conversation

chrischild
Copy link
Contributor

@chrischild chrischild commented Sep 24, 2019

Overview

Added a new configuration parameter (junit.jupiter.execution.timeout.mode) to determine if timeouts should be applied to annotated tests.

Couple of notes/questions:

  1. Since the default was to have it be enabled but still allow someone to comment the parameter out I wondered whether there was any reason to see if the value was set to "enabled" or not. To me there's no reason so I only checked to see if the value was "disabled" or "disabled_on_debug". Thoughts?

  2. Testing: I created one new test to make sure that setting the value to "disabled" truly did disable the timeouts. If there's a way to test the "disabled_on_debug" let me know.

Resolves #1959.


I hereby agree to the terms of the JUnit Contributor License Agreement.


Definition of Done

Copy link
Member

@sormuras sormuras left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't look into the implementation, yet -- but already found some issues.

@chrischild
Copy link
Contributor Author

I'm obviously hitting some errors but when I run gradlew test locally I'm seeing everything pass. What should I be running to see these errors?

@sormuras
Copy link
Member

./gradlew --scan --warning-mode=all -Dplatform.tooling.support.tests.enabled=true build

Without the '--scan' option, if you don't want to.

@chrischild chrischild closed this Sep 24, 2019
@chrischild
Copy link
Contributor Author

Closing for now. Thought I was closer to done but I looks like that was incorrect.

@marcphilipp marcphilipp self-requested a review September 25, 2019 07:57
@marcphilipp marcphilipp added this to the 5.6 M1 milestone Sep 27, 2019
Copy link
Member

@marcphilipp marcphilipp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

@sormuras
Copy link
Member

sormuras commented Sep 30, 2019

ManagementFactory.getRuntimeMXBean().getInputArguments()
...
Checking for the -agentlib:jdwp should suffice.
...

Parsing the input arguments feels a brittle to me. Isn't there another and safer way to determine whether a VM is running in debug mode at run time? /cc @raphw @forax

@raphw
Copy link

raphw commented Oct 2, 2019

ManagementFactory.getRuntimeMXBean().getInputArguments()
...
Checking for the -agentlib:jdwp should suffice.
...

Parsing the input arguments feels a brittle to me. Isn't there another and safer way to determine whether a VM is running in debug mode at run time? /cc @raphw @forax

Not really, you can check if the VM is listening to port 5005 but this does not help if the debugging port has changed. As far as I know, there is no good mechanism.

@sbrannen
Copy link
Member

sbrannen commented Oct 2, 2019

Not really, you can check if the VM is listening to port 5005 but this does not help if the debugging port has changed. As far as I know, there is no good mechanism.

Thanks for the feedback, @raphw.

So checking only for -agentlib:jdwp seems to still be the best option.

@@ -9,7 +9,8 @@
*/

module org.junit.platform.commons {
requires java.logging; // TODO Is "requires transitive java.logging" needed here?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the superseded TODO on-the-fly -- the module API of org.junit.platform.commons does not use types of java.logging.

@@ -9,7 +9,8 @@
*/

module org.junit.platform.commons {
requires java.logging; // TODO Is "requires transitive java.logging" needed here?
requires java.logging;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left the static modifier out on purpose -- because we need the module when running on the module path.

Otherwise, users have to add it via --add-module java.management or via their module descriptor(s).

@sormuras
Copy link
Member

sormuras commented Oct 8, 2019

Since the default was to have it be enabled but still allow someone to comment the parameter out I wondered whether there was any reason to see if the value was set to "enabled" or not. To me there's no reason so I only checked to see if the value was "disabled" or "disabled_on_debug". Thoughts?

With ce1892c I enforced enabled to be the actual value for when a mode value is passed.

Testing: I created one new test to make sure that setting the value to "disabled" truly did disable the timeouts. If there's a way to test the "disabled_on_debug" let me know.

That "disabled_on_debug" test case and the one that simulates an environment without JMX is still missing.

@chrischild
Copy link
Contributor Author

Ah I like it. Ok I'll take a peek and try and get those final missing pieces finished soon.

@chrischild
Copy link
Contributor Author

chrischild commented Oct 9, 2019

Huh I'm stumped on the JMX environment test. I tried my tests that I had created earlier and there was never a failure. I then commented out the java.management module change made by @sormuras in the platform module-info file

        requires java.logging;
//	requires java.management; // needed by RuntimeUtils to determine input arguments
	requires transitive org.apiguardian.api;

Also removed it from junit-platform-commons.expected to make sure a build should pass. I cleaned and then rebuilt and no errors occurred during the build.

I rechecked out this branch fresh and again removed the java.management line above and re-tested a clean build a third time and again there was no errors thrown. I don't see how this is possible.

Anyways I'll check in the new unit test for the disabled_on_debug value.

@sormuras
Copy link
Member

sormuras commented Oct 9, 2019

Huh I'm stumped on the JMX environment test. [...]

I'll add it later this week to this branch ... or after merging it. Or #2054 will provide such an integration test as a side effect.

* </ul>
*
* @since 5.6
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Javadoc should document the default value.

@@ -38,6 +42,9 @@
private static final ExtensionContext.Namespace NAMESPACE = ExtensionContext.Namespace.create(Timeout.class);
private static final String TESTABLE_METHOD_TIMEOUT_KEY = "testable_method_timeout_from_annotation";
private static final String GLOBAL_TIMEOUT_CONFIG_KEY = "global_timeout_config";
public static final String ENABLED_MODE_VALUE = "enabled";
public static final String DISABLED_MODE_VALUE = "disabled";
public static final String DISABLED_ON_DEBUG_MODE_VALUE = "disabled_on_debug";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should be private.

@sormuras sormuras changed the title Added timeout config parameter Add timeout config parameter Oct 11, 2019
@sormuras sormuras merged commit ddb8c61 into junit-team:master Oct 11, 2019
@sormuras
Copy link
Member

Thanks @chrischild

@chrischild
Copy link
Contributor Author

My pleasure. I wish I could've figured out the environment test though. I went back again and tried to see what else I might have missed but couldn't find a solution. I'll be keeping an eye on the Android integration test so I can see how it gets solved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

@Timeout should support debugging
5 participants