Community
Participate
Working Groups
JUnit is well integrated at the moment used to test java code. As there are many other projects which need to implement other testing tools, we should be a generalized form of the Junit framework as provide some extension points to build the implementations of other XUnit frameworks on top of it. I think this could be something at IDE level but as JUnit is part of JDT/UI, i filed this bug here. Here are some examples of implementing other xunit frameworks: * JsUnit (Ajax Tooling Framework - eclipse.org/atf) * PHPUnit (PHP Development Tools - eclipse.org/pdt) * HtmlUnit (Webtools Project - eclipse.org/webtools) * XMLUnit (Webtools Project - eclipse.org/webtools) * C(pp)Unit (C/C++ Development Tooling) As these are just examples, i really think that it's worth to refactor the code of the junit plugin to be just an implementation and have a abstract "unit testing framework" in eclipse. I'm looking forward for comments if this is possible in any timeframe or at least what others think about this.
+1 The time has come for api's to bubble out imho. Excellent idea! There are already plugins for ccpunit, jsunit, and simpletest/phpunit that exist as open source projects.
This is worth looking at, I encourage the interested parties to experiment with prototypes. The challenges are, as always: - Are the various testing framework really the same. Can you use the same terminologies in labels and views? Or will such a general test result view end up as a generic container that can show everything but nothing really well? - Similar examples are a. the 'Search' view, where we reuse the view, but result have there own pages. This works well, but it is not clear if there is really a user benefit or if users would rather have text matches in different views than Java matches. 'Help' for example moved out of the search view to have their own search result view. b. Call hierarchy view: There we decided against having a language neutral view as finding a title is already hard. Not all languauges have 'Calls'. XML for example has references.
I'd second Martin here. If this would just mean to take the existing JDT functionality, remove the term 'JUnit' from the UI texts, and push it down to the platform, that wouldn't be truly 'generic'. There are unit testing tools that differ in their usage from JUnit. In Haskell, for instance, we have a framework called QuickCheck that lets you define families of test cases (not single test cases) in so-called 'properties' (as in 'properties of functions', such as symmetry, transitivity etc.). The framework then generates a number of concrete test cases (about 100 or more) on the fly and runs them. If all succeed, you wouldn't be interested in these generated cases at all, but if there are failures, then the UI would have to be able to display an arbitrary number of them, with some detail structure and text, because they represent important counterexamples to the algorithm that you wanted to test with your test cases. QuickCheck properties are also integrated differently with the sourcecode (by convention). There is a bunch of properties for each function (and you have several functions in a source file). There are no suites. There are also no traces in Haskell. This means that you would have to make both UI panels of the current JUnit view part very generic. There wouldn't remain much more from the original than the red/green bar. (And, as a language IDE implementor, given my choice is either to implement that myself or else to re-use it, but to have to learn yet another set-of-interfaces-for-generic-view-pages-API, I'm not quite sure I wouldn't go with the first :-).
HTMLUnit, XMLUnit, and any of the JUnit extensions, already work with the existing Junit framework and views. Where this would be good is for other languages like PHP, CDT, DLTK, etc to give a basic hook into an existing framework without having to re-invent the wheel.
This would be nice as well, so that it would be easier to implement a FIT testing framework into Eclipse for running FIT tests.
I definitly see the point of Leif regarding non xunit testing tools. One thing which came to my mind is the pattern the Platform debug support uses for it's debug elements: having a default model (eg xunit) but be able to use an own model. In addition to that we could have a default presentation if not specified by testing plugin. Just some thoughts...
(In reply to comment #5) > This would be nice as well, so that it would be easier to implement a FIT > testing framework into Eclipse for running FIT tests. +1. We're taking a pot shot at execution of FIT like stuff, and plan on re-inventing/re-implementing the JUnit view. I'd be interested in contributing as well.
I would interested in contributing to a generic unit testing framework with default UI, too. I released the first milestone of ECUT at sourceforge with the goal of developing a plugin supporting CppUnit integration into Eclipse CDT as good as JUnit integration is. Maybe some code base parts could be used for a starting point ... If you are interested please have a look at http://sourceforge.net/projects/ecut. Please let me know what you think.
Best would be that interested parties propose a new sub-project (probably under the 'Tools' top-level project).
*** Bug 270371 has been marked as a duplicate of this bug. ***
