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.
This could be viewed as a successor issue to 39128. Test classes are generally not a part of a product in the same sense as other classes. As such they are distinct entities from 'ordinary' classes. I therefore propose that classes that extend TestCase, or as sub-class of TestCase, should be given the JUnit icon in the Filesystem panel. Further, NetBeans does not particularly support multiple test classes per 'ordinary' class. Indeed, some of its code assumes that there is a 1-to-1 relationship. However, JUnit is intended to have multiple test classes per ordinary class (thus allowing effective use of the setUp method). Sure, TestSuites can be written. But they are a pain to write and classes that should be included can at times not included. The IDE has the potential to make TestSuites irrelevant. I therefore further propose the following: 1. Executing a JUnit test on a class should run all the tests for which an instance of that class is created. 2. Allow the user to hide JUnit test cases and thus see just the product classes. This gives the user a feel for the product class structure. 3. Allow the user to hide the 'ordinary' classes and thus get to see just the JUnit tests. This gives the user a feel for the test structure.
I like JUnit icon idea. ad 1) I don't know how to find Test classes for a particular class other way than by name. The class can be used in other tests. ad 2,3) Tests can be stored in a separate filesystems than ordinary classes. Anyway it is more like enhancement for IDE explorer to enable various logical views. In 3.6 it can be done by projects in limited way, in future releases there will be hopefully better support.
ad 1) Tests are currently assumed to be under the same directory and the class to be tested. I imagine test identification being a search for all JUnit classes in that directory that invoke a constructor or call a method upon the class to be tested. A rigorous implementation would involve interogating class files for those tests. A simpler implementation would include any tests that match *SomeClass*Test where SomeClass is the name of the class to be tested. ad 2,3) I agree, this does seem like a more general enhancement. I guess, a similar line of thought would have interfaces and abstract classes having a distinct icon from classes with an ability to filter on them.
> ad 1) Tests are currently assumed to be under the same directory and > the class to be tested. I imagine test identification being a search > for all JUnit classes in that directory that invoke a constructor > or call a method upon the class to be tested. A rigorous > implementation would involve interogating class files for those > tests. A simpler As I already wrote. The class XXX, its constructor or a method can be used not only in XXXTest class. Other "friendly" classes can use class XXX in tests. > implementation would include any tests that match *SomeClass*Test > where SomeClass is the name of the class to be tested. I don't think it could work. For example, JavaNode extends Node, then exist JavaNodeTest, NodeTest. When you execute NodeTest and include any tests that match *Node*Test pattern, it accidentally executes also JavaNodeTest. Which is not desired. ad 2,3) Feel free to file an enhancement against module ide. Not only abstract classes and interfaces but also for example classes which extend JPanel would have a different icon, classes which extends something else would have a different icon. User could use custom icons for his classes (e.g. MyObject and its descendants would have the same custom icon).
ad1) TestSuites would most likely only refer to tests where there is direct access to a class. Indeed, it is quite likely that they will miss some classes that directly access the class under test, namely when the class is used as a part of test setup. I would therefore expect that identifying TestCases that directly access a classes constructor or methods would often cover at least what would be placed in a test case. Traversing further up the dependency tree, whilst desirable, is not necessary. These cases should only use functionality covered by test cases that have been made using direct access tests (at least in a TDD project). An additional but probably quicker to write possibility is to get NetBeans to construct/update TestSuites. This could be done through the Filesystem panel by allowing the user to select the test cases to be used and providing a 'create test suite' menu item under junit.
Since NetBeans 4.0, JUnit test classes are totally separated from application source files - both at the directory level and visually, too. So there is no need to provide a special icon for them. As regards running multiple test classes for a single source class, we discussed this possibility several weeks ago. We consider it an option but not for NetBeans 4.1/4.2.
Whilst it is true that there is now a test directory that contains test cases, it can contain other test entities such as stub classes and test utility classes. A distinct icon would help make the test cases stand out.
I filed a separate issue for special icon: http://www.netbeans.org/issues/show_bug.cgi?id=161326