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.

Bug 189045 - "Test Results"-Window: double click on a failed test should focus the file ("Expected exception [...]")
Summary: "Test Results"-Window: double click on a failed test should focus the file ("...
Status: NEW
Alias: None
Product: php
Classification: Unclassified
Component: PHPUnit (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: issues@php
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-29 09:27 UTC by daniela.waranie
Modified: 2011-02-10 08:53 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description daniela.waranie 2010-07-29 09:27:04 UTC
At the moment a double click forces the editor to jump to the line were the test failed. But when having other files opend and the focus of the editor is to another file (e.g. the class-under-test file) the user have to click to the test file to see the line were the error occured. 

It would be nice if in addition to "jump to the line" a "jump to the file" will be done.

If a test fails with "Failed asserting that [...]" the above works as expected, but if a test fails with "Expected exception [...]" the "jump to the file" is not processed.

Maybe the reason on "Expected exception [...]" is that there is no stack trace...
Comment 1 daniela.waranie 2010-07-29 10:10:18 UTC
I now realized that on "Expected exception [...]" do not "jump to the file" AND do not "jump to the line" at all. I think it is because of the missing stack trace (line number).

So it is no longer a bug. 
Now it is a feature request.

On "Expected exception [...]" failures netbeans should jump to the line, where setExpectedException is defined within the failing test method. If this is not possible a jump to the line "[...] function <function name of the test>[...]" should happen.

Would be nice to see this feature in the next release.
Comment 2 Tomas Mysik 2010-08-01 09:57:10 UTC
Can you please verify how it works with Java project? Thanks.
Comment 3 daniela.waranie 2010-08-01 13:17:52 UTC
No, sorry. I am not a Java developer - i am a PHP developer.

I am not sure, but i think the current behavior is the same for PHP and Java unit tests. For PHP a "jump to the setExpectedException method" would be best for me. On Java projects may be the above method have another name (depending on the unit test framework). So the general way is "to jump to the failing test methods first line", but in case of PHP i would like to see netbeans jump to the setExpectedException method line.

Right click on the "Expected exception [...]" message (in the Test Results Window) showes a "Go to source" option in the context menu, but no action takes place.

Right click on the "Expected exception [...]" message (in the Test Results Window) showes a "Go to source" option in the context menu, but no "jump to line" takes place.

Right click on the "Failed asserting <null> is true." message (in the Test Results Window) showes a "Go to source" option in the context menu, too. And for that message netbeans jumps to the line.

Maybe its because the stack trace is missing for "Expected exception [...]" messages...
Comment 4 Filip Zamboj 2010-09-15 12:37:56 UTC
batch reassigning
Comment 5 daniela.waranie 2010-09-16 07:55:49 UTC
Hi,

just for your information:
PHPUnit 3.5.0RC2 and newer now returns the stacktrace when a unit test case did not fire an exception if an exception was expected (setExpectedException()). This makes the Netbeans 'Test Resuls'-windows be able to navigate to the code line as desired. Means: a solution when using PHPUnit is available.

I am not sure if other frameworks (for PHP and/or Java) are printing a stacktrace in that case to the result xml, too. Please verify and close if other frameworks prints the stacktrace, too.
Comment 6 FabianBlechschmidt 2011-02-10 08:53:03 UTC
I think it is solved in the actually nightly build...

CLASSNAME::METHODNAME::METHODNAME with data set #0()
Failed asserting that 
Array
(
)
 is of type "int".
/Applications/xampp_very_old/xamppfiles/htdocs/project/tests/Frontend/User/Adapter/<Classname>.php:30

jumps to line 30 in classname.php, but the two methodnames in the title schould be fixed.