RE: [RDT-Dev] Unit Tests

[Chris W. <cwi...@ro...>]

Markus,
	Lots of stuff to cover...

First, I'm an idiot! I forgot to check everything in before asking you
to check it out. So a lot of code wasn't in CVS. Oops! This accounts for
many of the issues you saw.

> I've created a file unitTest.rb with the following content:
> -- start unitTest.rb --
> require 'rubyunit'
> class TestMessageStore < TestCase
> 
>    def testAddMessage
> 
>      assert_equals('+49177', '+49177')
>    end
> 
> end
> -- end unitTest.rb --

The Test::Unit plugin is meant to run Test::Unit test cases. I hadn't
tried it with a rubyunit based testcase yet...


> Here are some bugs I've encountered on both linux and windows:
> 
> 
> 1) When starting up a clean workspace, the Test Unit view shows up in
the
> inital
>    workbench

I will look into this.
 
> 2) The view is in the category TestUnit Category
> suggestion: create a category "Ruby" and add the TestUnit view to that
> category
>              and the Ruby Resources view as well

I'll change this.


> 3) ScrollLockAction.action.tooltip is not translated

I just fixed this and checked it in.


> 4) If there is no interpreter set, starting a test via Run->Test::Test
> Unit brings
>    up a dialog with two untranslated messages:
>    Dialog.launchWithoutSelectedInterpreter
>    Dialog.launchWithoutSelectedInterpreter.title

This worked with the code I forgot to check in. It should use the
messages you've already created for the debug.ui
plugin(RubyApplicationShortcut).


> 5) Selecting the menu entry Run->Run... shows an error-dialog:
>    Exception occurred creating launch configuration tabs, Reason: No
tab
> group
>    defined for launch configuration type
> "org.rubypeople.rdt.testunit.launchconfig"
> 
>    After clicking ok another dialog appears:
>    Problem Occurred: No tabs defined for launch configuration type
> Test::Unit
> 
>    After accepting that dialog as well, the Run-Dialog appears with a
> Test::Unit
>    entry in the list of configurations and "unitTest.rb" as child.
> Clicking on one
>    of these entries brings up the error dialogs described above.

This was because I forgot to check in the classes which created those
tabs/tab groups. It should work.


> The next 2 errors are windows specific:
> 
> 6) After launching unitTest.rb with Run->Test::Unit Test the following
> exception
>    occurs in the console. The view itself shows Runs: 1/1, Errors: 0,
> Failures: 0
>    and is neither red nor green. If I add a second test, 1/2 tests are
> shown as run.
> 
> /java/rdt-workspace-
> ssh/org.rubypeople.rdt.testunit/ruby/RemoteTestRunner.rb:59:in
> `send_tree': undefined method `name' for #<RUNIT::TestSuite:0x27ecba8>
> (NoMethodError)
>          from /java/rdt-workspace-
> ssh/org.rubypeople.rdt.testunit/ruby/RemoteTestRunner.rb:134:in
`started'
>          from /java/rdt-workspace-
> ssh/org.rubypeople.rdt.testunit/ruby/RemoteTestRunner.rb:1:in
`to_proc'
>          from /java/rdt-workspace-
...snip...

This may be due to the differences between RubyUnit and Test::Unit. I
can try and take a look and see if we can handle both.

> 7) After I started a unitTest.rb with Run->Test::Unit Test once, I get
the
> following
> error whenever I try to start unitTest.rb with Run->Run Ruby
Application:
> 
> java.lang.IllegalArgumentException: Port value out of range: -1
>          at java.net.ServerSocket.<init>(Unknown Source)
>          at java.net.ServerSocket.<init>(Unknown Source)
>          at
>
org.rubypeople.rdt.testunit.views.RemoteTestRunnerClient$ServerConnectio
n.
> run(RemoteTestRunnerClient.java:248)

This might have been due to old code. Can you try to recreate it with
the latest? 
 
> On Linux launching the test brings up the following message:
> 
> 8) /usr/bin/ruby: No such file or directory --
/home/markus/eclipse-3.0-
> rdt-gtk/workspace/SimpleTest//home/markus/eclipse-
> 3.0.1/workspace/org.rubypeople.rdt.testunit/ruby/RemoteTestRunner.rb
> (LoadError)
> 
> This one can be simply avoided by changing the return value of
> TestUnitRunnerConfiguration::getAbsoluteFilename()
> from
> return project.getLocation().toOSString() + "/" + filename;
> to
> return filename ;

Yeah this was the big hack I wanted you to check. I figured you might
know a better way of doing this...

> But I am not sure if using the RemoteTestRunner.rb as FILE_NAME
attribute
> in
> the RunnerConfiguration is the best solution, because it will lead to
> confusion
> when the FILE_NAME is displayed in the Run-configuration tab.
> Alternatively you
> could set the unit test as FILE_NAME and retrieve a path to the
> RemoteTestRunner.rb in a similar way as the path for the
eclipseDebug.rb
> file
> is retrieved. That includes also to get a valid path if the file does
not
> reside
> in a workspace but in the plugins directory after a proper
installation of
> RDT.
> (the current code also uses getBundle().getLocation(), but maybe some
> code reuse would be cleaner solution).

As a note, the JUnit plugin doesn't show the run-configuration for test
runs so I hide it too - hence the user never sees the filename (nor can
they enter program arguments). They deal with the test file, test class,
and project which are in the tab I created.

> Last but not least a general question about packaging:
> Why create a new plugin-project? Wouldn't it be sufficient to put
> the code into the existing plugins rdt.ui and rdt.launching?
> I think that RDT conists of quite a lot plugins already and adding
more
> makes
> it more complex. Particularly if we add another plugin project for
tests.

I was following the model that the JDT uses. I don't see why adding
another plugin adds much more complexity and it seems to me to be a nice
distinct plugin. Since the UI plugin is relatively small right now, I
suppose I could have combined them but I anticipate that to change as
time goes on. Basically it came down to "The JDT does it this way, why
shouldn't we?" - they are the benchmark for what we are trying to
achieve, yes?

Thanks,
Chris