Nicolai Parlog

I wondered about the same thing while implementing this. I decided to pick the easy way out and discuss it here. This seems to be the root for the problems...

> The hassle for Joda-Beans is that it doesn't know what the superclass properties are, as it only processes the source code of the subclass (and cannot see or query...

Now that #4 is merged I consider trying this out. I'd basically create two branches and implement both the more and the less generic version. Up- and downsides could be...

Hey Darkvater, I hope my reply isn't too late. Sorry it took so long. From [section 2.12](https://junit.org/junit5/docs/current/user-guide/#running-tests-capturing-output): > The data can be consumed via the `reportingEntryPublished()` method in a [`TestExecutionListener`](https://junit.org/junit5/docs/current/api/org.junit.platform.launcher/org/junit/platform/launcher/TestExecutionListener.html),...

As you propose in #651, we should build against 18/19, though, so let's do that.

I really like this idea, it just makes sense to have the option to bake the assumption that the test fails into the enable/disable logic. Straight-up winner on that front....

Thanks for looking into it, @Marcono1234. This is the relevant code: ```java /** * Evaluate all {@link ExecutionCondition} extensions registered for the * supplied {@link ExtensionContext}. * * @param context...

Two thoughts... ## Name We need to see whether there's a better name: `@NotWorking` describes expectations about the test ("it doesn't work"), but not about the test execution ("will it...

I thought about the name a bit more. We basically want to communicate three things: 1. the test is executed 2. a failing result isn't reported 3. a succeeding test...

To keep this issue and the related PR from stalling, I'm just gonna make the call and say the extension should be named `@ExpectedToFail`. @Marcono1234 Are you ok with that?...