I am seeing inconsistent jumping.

I am using the default functional controller test created by scaffolding (CalendarsControllerTest in my case).

I have 3 failures:

test_should_create_calendar
test_should_destroy_calendar
test_should_get_edit

Only double-clicking test_should_get_edit will jump to source. Double-clicking the others does nothing.
 

I'm waiting for a couple of utility methods in the ruby editing module for this. I'd like to implement this for 6.5, 
but if there won't be enough time, I think the issue can well be downgraded to P3 and addressed in the next release. 

(desc2 is unrelated to this issue, I think that problem was already discussed in the mailing list)

Hi Erno,
sorry I haven't done anything about this. Can you give me a really precise spec for exactly what it is you need? Exactly
what input you can pass me (for Test::Unit, and for RSpec), and exactly what output you need. Will passing a
DeclarationLocation (org.netbeans.modules.gsf.api.DeclarationLocation) back be sufficient?

I think a lot of the machinery for what you need already exists (in the Go To Declaration code), but is not available
directly at present.  If you can specify what you need (preferably as a set of (failing) unit tests!) that would help a
lot. I remember doing something for rspec while I was on vacation, but I think you still don't have everything you need
right?

Basically I need to be able to find the file object where a given test class is defined and the line number of a given 
method in that test class. For example say I have the following classes in the test/ folder:

class TestFoo < < Test::Unit::TestCase
  def test_bar
  end
end

module MosModule
  class TestBaz < < Test::Unit::TestCase
    def test_qux
    end
  end
end

Based on the class and method name I need the location of that method, e.g.:

TestFoo/test_bar => test/test_foo.rb:99 
MosModule::TestBaz/test_qux => test/test_baz.rb:88

For my purposes the FileLocation class, or any other class that contains either the sought after file object or the 
path to it and the line number of the method, would work fine as the return value (or rather a list of them as there 
might be more than one hits). So the signature of the method I need could be as follows:

List<FileLocation> findFileLocations(String className, String methodName, Project project)

So to confirm, you want a method that when given the String "TestFoo/test_bar", will return the DeclarationLocation
test/test_foo.rb:99, and when given the String "MosModule::TestBaz/test_qux", will return the DeclarationLocation
test/test_baz.rb:88, right?  (A DeclarationLocation also contains alternate locations, getAlternativeLocations(); these
are shown in a popup if you go to declaration for a class that is defined in multiple places for example.)

Do you have any other information than just the String? For example, the file of the test being run? Or the project?
Anything else?  Will this work for RSpec also or is the other method we added a while back sufficient?

Hi Erno,

I have implemented this ( changeset 255715fdf578 ).

org.netbeans.modules.ruby.RubyDeclarationFinder:
    /** Compute the declaration location for a test string (such as MosModule::TestBaz/test_qux) */
    public static DeclarationLocation getTestDeclaration(FileObject fileInProject, String testString) {

There are usage examples in the form of unit tests in RubyDeclarationFinderTest. The trick is you need to specify a Ruby
file in the same project as the test string - this is used to determine which code index among the various open projects
etc. that it should be using.

The result is a DeclarationLocation - which as I described earlier can have alternate locations. However, it turns out
that for methods, there will only be one. I added a unit test for this and discovered that it isn't possible to find
multiple locations for a method in a specific class (basically when added to collections they get merged as one). I
can't easily change that now at this late point. Basically, I allow for classes to be defined in multiple places, and
Open Type for example will show you all the places the classes are used. But when it comes to methods, if you have a
complete class name, you probably won't have the same -method- defined in multiple places. That seems unlikely, so
searches etc. optimize for it - and the equals/hashCode implementation ensures that when multiple entries are returned
from the index they are considered equal. To cut to the chase: for Module1:Module2:Class:method there will only be one
item returned.  Also, the method currently only searches in the user's project files - it doesn't search in the
libraries. That seems reasonable for your purposes, right?

Finally, will you always have a fully qualified name (modules/classes), or will it sometimes be just the class name
without the module? I can make the search a bit more flexible to try to handle this, but it doesn't do that now. The
unit test basically tests -exactly- the scenario you gave me and works for that.

Hi Tor,
thanks a lot! This is exactly what I needed and seems to work well in the Rails projects I use for testing; in the ruby-
debug project it doesn't seem to work though (more about that later). I added ruby.testrunner as a friend to gsf and 
gsf.api, hope that's fine -- I need access to gsf only because of the UiUtils#open method that can open a file based on 
an offset, should that be a problem I can always get the line number using NbDocument.findLineNumber and then use 
OutputProcessor#open instead.

I don't have the file being run available, but do have the project. Is any file object in the project fine as an 
argument for the method? Currently I'm passing Project#getProjectDirectory(), which seems to work. 

I should always have the fully qualified name, at least in the cases I've tried so far -- this depends on the Test/Unit 
framework and I have only limited control over what it passes.

Hi Erno,
glad to hear it's mostly working. Yes, I think the project directory will work. (It's used to look up the classpath, so
ClasspathInfo hopefully does the right thing with directories rather than just ruby files).

Instead of depending on gsf and UiUtils, you should use GsfUtilities.open() instead (in gsf.api). I'm going to remove
UiUtils soon (GsfUtilities is a pretty recent addition).

Let me know how to reproduce the Ruby project issue.

Actually now that I think about it - since you're using the project directory there might be an issue with the classpath
since not all directories in the project are part of the source path. Perhaps to be on the safe side, pass in one of the
source path directories instead (e.g. "lib" in Ruby projects, or "config" in Rails projects - but look it up via the
project api to find the Sources object obviously). Just an idea; I don't remember exactly how ClasspathInfo works (it's
based on a classpath fork) but that seems like it could do the trick.

Thanks for the tip on GsfUtilities, missed that since I browsed through only the api package. I removed the depency to 
gsf. Passing a source root didn't work either, but using a test source root works like charm for Ruby projects too.

I will still bug you about the rspec case shortly. 

Integrated into 'main-golden', will be available in build *200810111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/07d3e5134d63
User: Erno Mononen <emononen@netbeans.org>
Log: #135680 (part 1): Jump to source for passed test methods
- handling Test/Unit tests

Integrated into 'main-golden', will be available in build *200810140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a26c5d76eba0
User: Erno Mononen <emononen@netbeans.org>
Log: #135680: Jump to source for passed test methods
- handling rspec (on MRI only)

This is now fixed for all other cases except for RSpec tests when run on JRuby, so I'm downgrading to a P3. Doesn't 
work on JRuby due to different behaviour of ExampleMethods#implementation_backtrace that I need to use to locate the 
test file. I'll investigate other ways to achieve the same on JRuby.

Fixed for passed rspec tests on jruby in 394f868d1494, so the issue is completely fixed now.