Created attachment 116978 [details]
Proposed API change.

Please review. Thanks.

I guess the use case is that several variants of the test are already calling assertOutput, and you trust that the output will be correct and just want to check that the fix is offered in a variety of circumstances? If so, seems OK.

Could be used that way, but my current usecase is to be able to assert there are no fixes for the given warning. Another usecase could to verify that a fix is shown to the user even if the fix itself is not suitable for unit testing.

(In reply to comment #4)
> my current usecase is to be able to assert there
> are no fixes for the given warning.

Ah right, I see that after rereading the patch. Makes sense.

> Another usecase could to verify that a fix
> is shown to the user even if the fix itself is not suitable for unit testing.

Well TransformationContext is as strict as a Java API can be in delimiting side effects - in a well-behaved hint, everything a fix might do (*) should be easily testable. But there might be unusual cases where a fix depends on some sort of environmental context not captured by CompilationInfo which also cannot be easily tested.

Another case would be that the fix deliberately produces side effects not supported by TC, such as adding library dependencies (**) or updating a manifest file, and which are again not easily tested. Such fixes would clearly not be suitable for the Preview window. JG13 was not addressed for such cases, but I guess such fixes may directly implement org.netbeans.spi.editor.hints.Fix? From reading HintTest it looks like non-JavaFix Fix's are supported.


(*) Just noticed that "getResourceContent" and "getResourceOutput" are needlessly obscure ways of saying "readResource" and "writeResource". Too late I guess.


(**) Found ProjectDependencyUpgrader, with a non-I18N string. There seem to be no implementations...? There also seems to be a Map<String,String> options passed around to various methods which is always empty, and an unused ENSURE_DEPENDENCY? I will assume these are all placeholders for some future API or feature.

(In reply to comment #5)
> (In reply to comment #4)
> > my current usecase is to be able to assert there
> > are no fixes for the given warning.
> 
> Ah right, I see that after rereading the patch. Makes sense.
> 
> > Another usecase could to verify that a fix
> > is shown to the user even if the fix itself is not suitable for unit testing.
> 
> Well TransformationContext is as strict as a Java API can be in delimiting side
> effects - in a well-behaved hint, everything a fix might do (*) should be
> easily testable. But there might be unusual cases where a fix depends on some
> sort of environmental context not captured by CompilationInfo which also cannot
> be easily tested.
> 
> Another case would be that the fix deliberately produces side effects not
> supported by TC, such as adding library dependencies (**) or updating a
> manifest file, and which are again not easily tested. Such fixes would clearly
> not be suitable for the Preview window. JG13 was not addressed for such cases,
> but I guess such fixes may directly implement
> org.netbeans.spi.editor.hints.Fix? From reading HintTest it looks like
> non-JavaFix Fix's are supported.

Yes, non-JavaFixes are supported by the tests. These won't work in Inspect&Transform, and so are not good as the hint/inspection Fixes, but may be fine for suggestion/action Fixes (as these are never shown in the I&T).

> 
> 
> (*) Just noticed that "getResourceContent" and "getResourceOutput" are
> needlessly obscure ways of saying "readResource" and "writeResource". Too late
> I guess.
> 
> 
> (**) Found ProjectDependencyUpgrader, with a non-I18N string. There seem to be
> no implementations...? There also seems to be a Map<String,String> options
> passed around to various methods which is always empty, and an unused
> ENSURE_DEPENDENCY? I will assume these are all placeholders for some future API
> or feature.

More or less. There is an implementation that does this in Jackpot 3.0 on bitbucket - not yet tested with the new spi.java.hints. In general, the declarative fix infrastructure (JavaFixUtilities.rewriteFix) tries to automatically ensure that dependencies are correctly updated (reads the @since tag of the new method and asks PDU to update the dependency). But, in cases like upgrade from java.source's UiUtils to java.sourceui's ElementOpen, the new dependency cannot be inferred automatically, and that is the purpose of ENSURE_DEPENDENCY. It is currently used only from the declarative hints.

Thanks for the review:
http://hg.netbeans.org/jet-main/rev/5b00b0a7129e

Integrated into 'main-golden', will be available in build *201204030400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/5b00b0a7129e
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #209828: Enhance HintTest to allow asserting on warning's fixes, without actually applying any of the fixes