This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 252173 - Uncompilable code from create tests when remove unused imports on save is enabled
Summary: Uncompilable code from create tests when remove unused imports on save is ena...
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: JUnit (show other bugs)
Version: 8.1
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Theofanis Oikonomou
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-30 07:27 UTC by cezariusz
Modified: 2015-09-22 13:40 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cezariusz 2015-04-30 07:27:13 UTC
Product Version: NetBeans IDE Dev (Build 201504280001)
Java: 1.8.0_45; Java HotSpot(TM) 64-Bit Server VM 25.45-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b14
System: Windows 7 version 6.1 running on amd64; UTF-8; pl_PL (nb)

1. Turn on Tools -> Options -> Editor -> On Save -> Remove Unused Imports
2. Create a test class using Tools -> Create/Update Tests

The generated code will be full of errors because of missing imports for "fail" and "assertEquals".
Comment 1 Svata Dedic 2015-09-22 12:52:22 UTC
The behaviour is as follows:

1/ the test generator instantiates a template, which contains `import static' 
statement, which imports members from Assert class. At that time, no call to Assert methods is present in the source (will be generated later).

2/ the template file is saved, so that remove unused imports runs. Since there are no calls to Assert.*, the unused static import is removed; the file is saved.

3/ the test generator generates code, assuming that simple identifier `fail' resolves to Assert.fail; it does not check whether the import is present.

recommended solution:
* the JUnit code generator should check whether the simple ident actually resolves to the desired type. Template could be customized by the user, so the import could be eventually removed/changed.

* we should define a flag for templates, which would suppress unsued import removal. Especially for templates, it is likely that instantiated template will be worked on (either by the user or some code generator) - the removal should be done on the final save.
I am not positive if all on-save tasks should be suppressed when creating from template - IMHO not.
This flag must be propagated by the EditorModule's operation listener or lower, as higher layers do not have the information that the document is being saved because of creation from template. The flag should be made a part of on-save task API so it can be tested by features.
Comment 2 cezariusz 2015-09-22 12:59:37 UTC
Or simply do not invoke on-save actions when it's an automated save (step 2/).
Comment 3 Svata Dedic 2015-09-22 13:40:42 UTC
(In reply to cezariusz from comment #2)
> Or simply do not invoke on-save actions when it's an automated save (step
> 2/).

For example, Organize Imports (members), reformat will bring template contents in line with project's code style. I would rather create a flag for an operation to decide whether it applies on 'automated' creation.