Re: [tde-general] Brainstorm Eclipse extension points

[Samuel ]s. <sa...@Up...>]

On Fri, Jan 02, 2004 at 11:22:47PM -0500, David Corbin wrote:
> On Friday 02 January 2004 19:29, Samuel ]slund wrote:
> > Combining Jester with reporting throught JUnit ?
> > That could make use of pushing failures/notes from the outside.
> 
> I'm not sure I understand.

I was thinking about using idle CPU to run "mutation tests" like Jester
for java. (jester.sourceforge.net)
The results should be reported somewhere, but it is probably better to
add some kind of TODO item.

> > Can we hide JUnit if a second testrun succedes after JUnit has been
> > poped up because of a testfailure?
> 
> I'm not sure I understand this one either.  Do you mean "collapse" the 
> FastView so it's just an icon?  Get rid of the view?

If a test fails JUnit pops up. If a following testrun succeeds whatever
was ontop before should get back on top.

> > > 2) When refactoring 'Convert Local Variable to Field", it would nice to
> > > be able to add "setUp()" as an additonal choice for initialization point.
> > > (There's an open bug about this one I think)
> >
> > There is more magic that could be done here.
> > Most of the time I would use that feature I already have one or two
> > local variables with the same name, type and instantiation in other
> > test functions. Taking that refactoring step too would be helpfull.
> 
> Do you mean, "merge two classes and extract the common parts into  a base 
> class" refactoring?  3.0 is including the ability for external refactorings 
> to be added.

That sounds realy nice, but I was thinking that when I extract something
because of duplication I'd like the duplication to be replaced too.

> > 5) A way to track which files are edited and viewed. This could make
> > "magic" for chosing the right test/production code to jump to easier.
> > (We could also add jumps as a part of the class menu in the package
> > explorer.)
> 
> I think Eclipse provides this information already.  Are you saying the logic 
> for matching prod-to-test would be dependent on what editors are open?

No, but we could possibly use that information to make it more
"dwim"/inteligent.

> > 6) Can we get dependency information from the compiler?
> > Like what was used when compiling a specific function?
> 
> 3.0 has a call tree view, but it's not bound to the compiler.  I would assume 
> static AST analysis would be able to reveal what classes are referenced 
> *fairly* easily.

I was thinking more about which parts (methods/fields) that was
accessed. That could give us some more options for finding
test/production code connections.


//Samuel