Eclipse generate "allocated object never used" errors in jmockit test - eclipse

Using JMockIt 1.12 and Eclipse Luna and I get "The allocated object is never used" errors.
I tried:
#Test
public void testNullCase() {
new NonStrictExpectations() {{
TestClass.getPlug();
result = null;
}
...
};
To use SuppressWarnings I had to use something ugly like this:
#Test
public void testNullCase() {
#SuppressWarnings("unused")
NonStrictExpectations dummy = new NonStrictExpectations() {{
TestClass.getPlug();
result = null;
}
...
};
How to do this in a nicer way or am I missing something using JMockIt?

This warning can be turned off via:
opening the dialog Window/Preferences
going to section Java/Compiler/Errors&Warnings/Potential Programming problems
disabling Unused object allocation.
If you want to make that change persistent outside a particular Eclipse workspace, you can use the workspace mechanic. Or you could move the #SuppressWarnings("unused") to the test class to disable it for all tests in the class.

Related

Using NUnit, (how) can I test code that sets Thread.CurrentThread.Name?

Consider this Test
[TestFixture]
class Sample
{
[Test]
public void Test()
{
Thread.CurrentThread.Name = "Foo";
}
}
If I debug this test, it passes without error.
If I run this test, it fails with the following exception
System.InvalidOperationException : This property has already been set and cannot be modified.
In run mode, the test's thread's name is "NonParallelWorker".
In debug mode, the test's thread's name is null
As a constraint, assume the code-under-test is not allowed to change, and attempts to set the thread's name, without checking for null first.
E.g.
public void SampleMethodUnderTest()
{
// It is important that this method gets to set this field.
Thread.CurrentThread.Name = "Important Value";
}
My search through the documentation and other's posts has come up dry...
Question
Is there any way to disable/modify NUnit's thread-naming behavior?
Try adding the RequiresThreadAttribute.
[TestFixture]
class Sample
{
[Test, RequiresThread]
public void Test()
{
Thread.CurrentThread.Name = "Foo";
}
}
I think this will work currently, although the fact that this creates an unnamed thread may be an implementation detail, and not something that will necessarily work reliably going forward, I'm not sure. The alternative of course is to create your own user-controlled thread in the test, and pass any exceptions back to NUnit.

GWT Arrays.asList not working on interface types

Working on a GWT project (2.7.0), i have experienced a very odd client code behaviour.
The following code throws the error "SEVERE: (ReferenceError) : Ljava_io_Serializable_2_classLit_0_g$ is not definedcom.google.gwt.core.client.JavaScriptException: (ReferenceError) : Ljava_io_Serializable_2_classLit_0_g$ is not defined".
The error occurs, when calling Arrays.asList() with a parameter, that has an interface type.
Is this expected behaviour or a GWT bug?
// Working
Integer n1 = 1;
Arrays.asList(n1);
// Not working
Serializable n2 = 1;
Arrays.asList(n2);
GWT 2.7's Super Dev Mode (and from the _g$ in your class literal field, I think that is what you are using) has been observed having other issues like this, but when compiled the issues go away.
If this is indeed what you are seeing, the issue seems to be fixed in 2.8, not yet released: https://groups.google.com/d/topic/google-web-toolkit/RzsjqX2gGd4/discussion
This behavior is definitely not expected, but if you can confirm that this works correctly when compiled for production and in GWT 2.8, then we at least know the bug is fixed.
Well, the typical use of Arrays.asList would be
Object myObj = new Object();
List theList = Arrays.asList(new Object[] {myObj});
This works in GWT with any kind of interface/class/enum you throw at it.
EDIT : I've tested this with GWT 2.5.1 :
public class Foo implements EntryPoint {
public static interface MyInterface {
}
public static class MyObject implements MyInterface {
}
public void onModuleLoad() {
MyInterface myObject = new MyObject();
List<MyInterface> myList = Arrays.asList(myObject);
}
}
Isn't it possible that the problem lies somewhere else?

SWTBot Recorder Generated code bot.contextMenu not found

The following is the code generated by SWTBot Recorder.
public class UserInterfaceTester extends SWTBotEclipseTestCase {
#Test
public void TableTest() {
bot.tree().getTreeItem("wtrt").select();
bot.contextMenu("Expand All").click();
bot.tree().getTreeItem("wtrt").getNode("erwtesg(3)").getNode("esrgg").select();
bot.contextMenu("Open Application Metadata File").click();
bot.text().setText("9.5");
bot.text().setText("Synopsys");
bot.text().setText("3.2");
}
}
But when I try to put that in my Test case to run inside my project it shows error in bot.contextMenu. It says "The method contextMenu(String) is undefined for the type SWTEclipseBot".
Extending SWTBotEclipseTestCase automatically gives me bot object which is
protected SWTEclipseBot bot = new SWTEclipseBot();
But it says it is a deprecated version. It says "Deprecated. use SWTWorkbenchBot. This will be removed from future releases"
Hence I tried
SWTWorkbenchBot bot = new SWTWorkbenchBot(); // by removing extends SWTBotEclipseTestCase
that to did not work. What is the issue? Can some one help?
The ContextMenuHelper class should help with this, and it works round some bugs with dynamic context menus. try:
SWTBotMenu menu =
new SWTBotMenu(ContextMenuHelper.contextMenu(bot.tree(), "Expand All"));
menu.click();

Inter Type Declaration on Compiled Class File

Is it possible to do Inter Type Declarations with AspectJ on Compiled Class Files at Load Time Weaving?
As an example: I compile some Groovy code and want to add fields or methods with IDT.
Update:
Oh my goodness, you do not need reflection to access members or execute methods. Eclipse shows errors in the editor, but you may just ignore them, the code compiles and runs fine anyway. So the aspect is really much more strightforward and simple:
public aspect LTWAspect {
public static String Application.staticField = "value of static field";
public String Application.normalField = "value of normal field";
public void Application.myMethod() {
System.out.println(normalField);
}
void around() : execution(void Application.main(..)) {
System.out.println("around before");
proceed();
System.out.println("around after");
System.out.println(Application.staticField);
new Application().myMethod();
}
}
Original answer:
Yes, but you have a hen-and-egg problem there, i.e. you cannot just reference the newly introduced fields from your LTW aspect code without reflection. (The last sentence is not true, see update above.) Plus, in order to make your LTW aspect compile, you need the classes to be woven on the project's build path so as to be able to reference them. Example:
Java project
public class Application {
public static void main(String[] args) {
System.out.println("main");
}
}
AspectJ project
import org.aspectj.lang.SoftException;
public aspect LTWAspect {
public static String Application.staticField = "value of static field";
public String Application.normalField = "value of normal field";
public void Application.myMethod() {
try {
System.out.println(Application.class.getDeclaredField("normalField").get(this));
} catch (Exception e) {
throw new SoftException(e);
}
}
void around() : execution(void Application.main(..)) {
System.out.println("around before");
proceed();
System.out.println("around after");
try {
System.out.println(Application.class.getDeclaredField("staticField").get(null));
Application.class.getDeclaredMethod("myMethod", null).invoke(new Application());
} catch (Exception e) {
throw new SoftException(e);
}
}
}
So, e.g. in Eclipse you need to put the Java project on the AspectJ project's build path under "Projects" because only then it can see Java class Application on which you want to declare members. After compilation you just start the Java project and do LTW on the aspect project (don't forget an aop-ajc.xml referencing LTWAspect).
In my example above I declare a static member, a non-static ("normal") member and a non-static method. My advice prints the static member and calls the non-static method, both via reflection. The non-static method then prints the non-static member, again via reflection. This is not nice, but it works and proves the ITD in combination with LTW is possible. There might be a more elegant way, but if so I am unaware of it. (Update: There is a more elegant way: Just ignore the errors marked by Eclipse IDE, see above.)
Program output
around before
main
around after
value of static field
value of normal field

SWTbot tests not behaving as expected

So I'm testing an eclipse plugin with SWTbot and I'm not getting the result I'm expect - when I cut the test down it turns out that the problem isn't with the bot it's with some code that I've copied accross from another part of the program (where it was fully functional)
The following code...
#RunWith(SWTBotJunit4ClassRunner.class)
public class Tests {
private static SWTWorkbenchBot bot;
#BeforeClass
public static void beforeClass() throws Exception {
bot = new SWTWorkbenchBot();
bot.viewByTitle("Welcome").close();
}
#Test
public void maybeThisWillWork(){
IWorkbenchWindow activeWorkbenchWindow = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
System.out.println("A");
IWorkbenchPage activePage = activeWorkbenchWindow.getActivePage();
System.out.println("B");
}
#AfterClass
public static void sleep() {
System.out.println("In the sleep function");
bot.sleep(10000);
}
}
Gives me the output -
A
In the sleep function
Rather than the expected
A
B
In the sleep function
Any ideas?
you may need to run your test as JUnit plugin test. Have you tried that?
So it turns out that the answer is thus (also a nice advantage of stackoverflow is that I actually solved this somewhere else, remembered I'd had a similar problem and then had to come back to stackoverflow to remind myself of the details)
SWTBot isn't running in the UI thread proper hence the null pointer errors, what I had to do was use effectively:
Display display = bot.getDisplay();
display.syncExec(objectThatdoesthethingiwanttogetdoneintheUIthread);
System.out.println(objectThatdoesthethingiwanttogetdoneintheUIthread.results);
...and that got things working...