I'm not much of an Eclipse guru, so please forgive my clumsiness.
In Eclipse, when I call Assert.assertEquals(obj1,obj2) and that fails, how do I get the IDE to show me obj1 and obj2?
I'm using JExample, but I guess that shouldn't make a difference.
Edit: Here's what I see:
(source: yfrog.com)
.
Comparison with failure trace is not a easy task when your object is a little bit complex.
Comparison with debugger is useful if you have not redefined toString(). It remains still very tedious as solution because you should inspect with your eyes each objects from both sides.
Junit Eclipse plugin offers a option when there is a failure : "Compare actual With Expected TestResult". The view is close enough to classic content comparison tools :
Problem is that it is avaiable only when you writeassertEquals() with String objects (in the screenshot, we can see that the option in the corner is not proposed with no String class) :
You may use toString() on your object in assertion but it's not a good solution :
firstly, you correlate toString() with equals(Object)... modification of one must entail modification of the other.
secondly, the semantic is not any longer respected. toString() should return a useful method to debug the state of one object, not to identify an object in the Java semantic (equals(Object)).
According to me, I think that the JUnit Eclipse plugin misses a feature.
When comparison fails, even when we compare not String objects, it should offer a comparison of the two objects which rely on their toString() method.
It could offer a minimal visual way of comparing two unequals objects.
Of course, as equals(Object) is not necessarily correlated to toString(), highlighted differences should be studied with our eyes but it would be already a very good basis and anyway, it is much better than no comparison tool.
If the information in the JUnit view is not enough for you, you can always set a exception breakpoint on, for example, java.lang.AssertionError. When running the test, the debugger will stop immediately before the exception is actually being thrown.
Assert.assertEquals() will put the toString() representation of the expected and actual object in the message of the AssertionFailedError it throws, and eclipse will display that in the "failure trace" part of the JUnit view:
(source: ibm.com)
If you have complex objects you want to inspect, you'll have to use the debugger and put a breakpoint inside Assert.assertEquals()
What are you seeing?
When you do assertTrue() and it fails, you see a null.
But when you do assertEquals, it is supposed to show you what it expected and what it actually got.
If you are using JUnit, mke sure you are looking at the JUnit view and moving the mouse to the failed test.
FEST Assert will display comparison dialog in case of assertion failure even when objects you compare are not strings. I explained it in more detail on my blog.
If what you are comparing is a String then you can double click stack element and it will popup a dialog showing the diff in eclipse.
This only works with Strings though. For the general case the only way to see the real reason is to install a breakpoint and step into it.
Related
With intellij idea, how do I find out what makes a variable be visible?
An example of when it is hard:
Suppose you look at class A, and you see a variable something. If you jump to source you see that it's defined in trait X. But you don't extend trait X directly. What do you extend, then, that makes this variable visible? If you have a deeply nested hierarchy, tracking can be hard.
Any recommendations or solutions?
EDIT: Please vote for the feature if you're interested: http://youtrack.jetbrains.com/issue/IDEA-124369
I don't think that IntelliJ IDEA has any shortcut for "finding what makes a variable visible".
However you can determine it using the "Find Usages" option (Alt + F7). For example:
import java.nio._
object TempObj extends App {
def func = 2
val p = file.Paths.get("some-path")
func
}
So Find Usages on "file", tells you that its from the Package "file" (in heading of the new Tab it also shows the complete package name, ex: Find Usages of java.nio.file in Project Files).
Whereas Find Usages on func will tell you that its a Method (And the Tab heading now says: Find Usages of func() in Project and Libraries)
So now in way you can determine, what exactly makes the variable visible. This also works for imports since it shows the package from which it is imported and you can then look for import of that packages.
I know of two almost-solutions to this problem.
Go-to-declaration, as you mentioned, solves this problem in the case of local variables.
More generally, the "find usages" feature gives you a neat little breakdown by type and file of different uses of the variable. From this you can see if it's involved in a static import.
It's not perfect, but with a moment's thought these two are generally sufficient to figure out what you want.
Use ctrl+b or F4 to jump to source code. Alternatively you can use ctrl+shift+a to get option/action. You can find shortcuts at http://gaerfield.github.io/ide-shortcuts/ as well. Hope it will help.
From what I understood you want to see the code that creates an Object you use, for instance Mystery someMystery;.
That gives you two options to populate someMystery:
someMystery = ... where ... is your code to populate
someMystery and if that is the case you should follow
that code (with ctrl+B as far as you need to) to the point where it
actually creates the Mystery object.
Use CDI to populate that object instance for you, in which case you should look into the CDI mechanism in order to see in what way the object instance is populated.
In either way IMO there is no way to know for sure if the someMystery instance is of some more concrete class than Mystery, because it is decided in runtime, not in compile time, so your next bet would be to run the program in debug and see what object goes into someMystery, although you are not guaranteed to get the same type of object every time.
PS. My answer is based entirely on my java understanding of the topic, can't say if it is valid for scala also.
This might not be exactly the answer you were hoping to get.
However, quoting yourself,
If you have a deeply nested hierarchy, tracking can be hard.
Have you considered using composition over inheritance? Perhaps this would remove the need for the feature you are looking for.
Deeply nested hierarchy doesn't sound good. I understand your pain about that.
When you override vals or defs there is a little circle next to the line number that shows where it is from even when it is from nested hierarchy. Hovering over vals with the command key down also shows you a little tooltip where it is from.
Does this help?
https://youtu.be/r3D9axSlBo8
if you want class, field or method to be visible, you need to implement them as public. If it was your question.
Eclipse (any version AFAIK) has some weird behavior related to folding in Java code. Suppose I’m editing this class:
class A {
String field;
#Nonnull
Object method(){
// whatever
}
}
If folding is enabled and I tell it to collapse everything (it’s Control-NumSlash in mine, but that might be customized), the method is correctly folded, i.e. it shows only Object method()... for the method. All good ’till now.
The part that bothers me is that if I move the cursor right after field;, press Enter, and type something like “public”, and then stop for a second, Eclipse automatically folds that word into the method below.
That might seem reasonable (presumably it assumes I wanted to add that qualifier to the method); but in practice what I’m actually doing is trying to add a new method, and paused for a moment to think about its return type or maybe its name. (If I wanted to modify the method I’d unfold it first, since it might already have that qualifier, folded.)
I hate this “feature” with passion, but I can’t for the life of me find out how to disable it, nor even which of the damned mess of plugins (that Eclipse keeps insisting I should not be allowed to remove) is responsible for it so I can file a bug report.
So, does anyone know (1) where does that behavior come from, and hopefully (2) how can I get rid of it but keep manual folding? Thanks!
(For the record, I’m using Kepler SR1, but this behavior goes back a really long time, at least five years or so.)
I don't believe there's any way to prevent it from doing that unless you just make a habit of putting a semicolon ; or closing curly brace } after public which prevents the Object method(){.. from 'folding' it up. I believe it's written to fold everything up until the closest semicolon which is why #Nonnull is also included.
The only options for folding I can find are located in Window > Preferences > Java > Editor > folding
I would consider this to be a bug, or just a feature that had unintended side effects.
Funny enough, if you put almost any symbol or misspell public it wont fold it.
I started my adventure with Sonar ;)
Sonar with it's default configuration has PMD UnnecessaryLocalBeforeReturn error set on major level.
List<Todo> filtered = em.createQuery(query).getResultList();
return filtered;
It means for me that I should change this code above in one line.
It's really interesting for me because I recommend my colleagues to make this "unnecessary" local before return.
I think it ease debugging. When I set up breakpoint on return line, I'm sure that when I get there this value will be ready and I don't have to make selection over my statement or do "Step over Expression".
Beside I believe it has positive impact on reducing return points in methods.
My question is: Are there some kind of explanations/discussions why errors from projects such as Checkstyle, PMD, FindBugs, etc. were acknowledged as errors?
If your point is only viewing the content of the List, you may just as well either put the break point in the caller of the method. The other option is to put a break point and evaluate the value (Eclipse & IntelliJ do it nicely).
Why is it consedered as a bad practice ?
You just add a reference to a variable while it is not necessary.
This just increase the workload on the Garbage Collector.
I am working on an Eclipse JDT plugin that requires parsing large numbers of source files,
so I am hoping to use the batch method ASTParser.createASTs(). The parsing executes without errors, but within the CompilationUnit instances it produces, many of the org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding instances have had their scope field set to null. This setting to null is occurring in the CompilationUnitDeclaration.cleanUp() methods, which are invoked on a worker thread that is unrelated to my plugin's code (i.e., my plugin's classes do not appear on the cleanUp() method call stack).
My parsing code looks like this (all rawSources are within the same project):
ASTParser parser = ASTParser.newParser(AST.JLS3);
parser.setResolveBindings(true);
parser.setStatementsRecovery(true);
parser.setBindingsRecovery(true);
parser.setIgnoreMethodBodies(false);
parser.setProject(project);
parser.createASTs(rawSources.values().toArray(new ICompilationUnit[0]), new String[0], this, deltaAnalyzer.progressMonitor);
Alternatively, I can execute the parsing this way, and no such problems occur:
for (ICompilationUnit source : rawSources.values())
{
parser.setResolveBindings(true);
parser.setStatementsRecovery(true);
parser.setBindingsRecovery(true);
parser.setIgnoreMethodBodies(false);
parser.setProject(project);
parser.setSource(source);
CompilationUnit ast = (CompilationUnit)parser.createAST(deltaAnalyzer.progressMonitor);
parsedSources.add(deltaAnalyzer.createParsedSource(source, ast));
}
This issue occurs in both Helios and Indigo (the very latest release build). I filed a bug in Eclipse Bugzilla, but if anyone knows of a way to work around this--or if I am using the API wrong--I would greatly appreciate your help.
Byron
Without knowing exactly what your exception is, I can still offer 2 suggestions:
Have a look at org.eclipse.jdt.ui.SharedASTProvider. If you are not making any changes to ASTs, this class may provide a more robust way of getting the ASTs.
Play around with some of the settings that you are using. Do you really need bindingsRecovery set to true? What about statementRecovery? Setting these to false may help you.
i have this Problem with my test ..the
driver.findElement(By.xpath("//html/body/div[2]/div/div/div[2]/div[2]/div/div[2]/div/div/div/div/div/div/div/ul/li[2]/a[2]/em/span/span/span")).click();
don't find the element.
the eclipse show this message of error
Cannot locate a node using
//html/body/div[2]/div/div/div[2]/div[2]/div/div[2]/div/div/div/div/div/div/div/ul/li[2]/a[2]/em/span/span/span
EDIT : Post edited to reflect answer to actual problem. Original answer follows.
Long XPath expressions are fragile, and tests are prone to fail when relying on them : a completely unrelated change somewhere else in the document can mess everything up, and even if you're aware of the problem, the tests' code is just harder to maintain.
In this particular case, since the site is generated by GWT, it's even worse - there is little control over the actual HTML changes. A good solution when using GWT is to use the ensureDebugId method (see link in comments).
Are you sure that this XPath expression is correct ? Does other tests work with this driver ?
I'd recommend avoiding the use of long XPath expressions like that - wouldn't it be safer in the long term to start the expression at an id-specified div somewhere in the page rather than at the root of the DOM ?