I am using Junit 4.x to test a method.
The method under the test is expected to throw an IllegalArgumentException. The method is a blocking method (synchronous) which internally makes a remote ssh connection executes a script and captures result, or throws exception.
To test this, I have written my JUnit test code as below.
#Test (timeout=3000, expected=IllegalArgumentException.class)
public final void testReadFolderWithInvalidFolder() {
final String folder = "/home/rv_nath/xxxyyyZzz";
rfc.readFolder(folder);
}
The testReadFolder() method above is supposed to wait upto 3 seconds (becoz of timeout=3000) before checking whether the expected exception is thrown or not). But it returns immediately, reporting that the test case has failed.
Can anyone help me figure out what is going wrong in the above. If more details required, let me know.
Here is the failure trace from Junit...
java.lang.AssertionError: Should have thrown IllegalArgumentException.
at org.junit.Assert.fail(Assert.java:91)
at com.comviva.remotefilebrowser.server.RemoteFileCaseTest.testReadFolderWithInvalidFolder(RemoteFileCaseTest.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
Is there a bug in Junit4 timeout implementation, or am I missing something here?
Because, if I run the test case in debug mode (and trace through it, then it takes time to finish the remote execution, but it definitely works and the test case passes). The problem occurs only if I choose to run the test case, instead of debug it.
thanks and regards,
RV
Sorry for the above naive question. It was a problem with the way, I used JSch library routines for reading remote data.
Just posting here, so it may help novice users like me :)
The JSch library was throwing some exception, which I was not capturing properly. The called method was capturing the exception and was returning immediately. After the correction, it works correctly.
Related
Is it possible to catch the following exception?
"Failed to get matching snapshots"
Most of the stability issues with XCUITest is due to not having a proper method to wait for element to exist. Tried exists(), waitforexistence(),xctwaiter waits etc. In all cases it fails randomly with above error. Is there a way we have handle this exception do a retry in our tests itself.
You should stick to combination of two methods
Use it for every flaky element
button.waitForExistence()
button.tap()
We have developed Server-Client application using CORBA.
When client try to make a request to Server, we get below error message.
Jan 14, 2018 10:00:22 AM com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl writeLock
WARNING: "IOP00410202: (COMM_FAILURE) Connection close: rebind"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 202 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionCloseRebind(Unknown Source)
at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectionCloseRebind(Unknown Source)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.writeLock(Unknown Source)
at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendFragment(Unknown Source)
at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendMessage(Unknown Source)
at com.sun.corba.se.impl.encoding.CDROutputObject.finishSendingMessage(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.finishSendingRequest(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(Unknown Source)
at org.omg.CORBA.portable.ObjectImpl._invoke(Unknown Source)
What we observed that, whenever client make continuous 5-6 requests, client gets the above error for particular 2-keys. Sometimes first 4 requests work correctly but get the error on last request. Or sometime gets the error on first request then remaining requests work correctly.
I have done enough search on google but did not find the solution.
I hope someone will help me here.
COMM_FAILURE means the underlying connection failed somehow. In your case, you're experiencing a premature close of the connection.
You reported only a warning message. Do you experienced an COMM_FAILURE exception in your code or are you seeing this only in log messages? In my guess this seems only a ORB internal log message and, if I'm right, it's not a problem at all.
In some very simple hello world code you could experience this when you execute the server without a orb.run() in your server, or even you're doing a System.exit while processing the invocation.
In other hand, I recommend you to use http://JacORB.org implementation instead of old and unsupported Sun implementation for CORBA (built-in the Oracle JVM). JacORB is a mature implementation and it's compliant to CORBA 3.0 spec.
When my test runs into a critical failure such as tapping an invalid element the Automation Instrument attempts to restart the test from the beginning which results in a lot of errors and can even lag my system, making it difficult to stop the test. I don't have the repeat option enabled. Is there a way of preventing this behavior?
I reckon what you can do is: try capturing when your test runs into a failure by means of a try/catch block.
When your test fails, it will jump inside the catch block and you can stop it there.
Maybe something like this.
try {
// Run your tests
} catch (exception){
UIALogger.logFail("Test failed with error message: " + exception.message);
}
I think that the logFail() method should be enough to keep your tests from running indefinately.
Have a system build using C++ Builder 2010 that after running for about 20 hours it starts firing of assertion failures.
Assertion failed: xdrPtr && xdrPtr == *xdrLPP, file xx.cpp, line 2349
Tried google on it like crazy but not much info. Some people seem to refer a bunch of different assertions in xx.cpp to shortcomings in the exception handling in C++ Builder. But I haven't found anything referencing this particular line in the file.
We have integrated madExcept and it seems like somewhere along the way this catches an out of memory exception, but not sure if it's connected. No matter what an assertion triggering doesn't seem correct.
Edit:
I found an instance of a if-statement that as part of it's statement used a function that could throw an exception. I wonder if this could be the culprit somehow messing up the flow of the exception handling or something?
Consider
if(foo() == 0) {
...
}
wrapped in a try catch block.
If an exception is thrown from within foo() so that no int is returned here how will the if statement react? I'm thinking it still might try to finish executing that line and this performing the if check on the return of the function which will barf since no int was returned. Is this well defined or is this undefined behaviour?
Wouldn't
int fooStatus = foo();
if(fooStatus == 0) {
...
}
be better (or should I say safer)?
Edit 2:
I just managed to get the assertion on my dev machine (the application just standing idle) without any exception about memory popping up and the app only consuming around 100 mb. So they were probably not connected.
Will try to see if I can catch it again and see around where it barfs.
Edit 3:
Managed to catch it. First comes an assertion failure notice like explained. Then the debugger shows me this exception notification.
If I break it takes me here in the code
It actually highlights the first code line after
pConnection->Open();
But it seems I can change this to anything and that line is still highlighted. So my guess is that the error is in the code above it somehow. I have seen more reports about people getting this type of assertion failure when working with databases in RAD Studio... hmmmm.
Update:
I found a thread that recursively called it's own Execute function if it wasn't able to reach the DB server. I think this is at least part of the issue. This will just keep on trying and as more and more worker threads spawn and also keep trying it can only end in disaster.
If madExcept is hinting that you have an out of memory condition, the assert could fail if the pointers are NULL (i.e. the allocation failed). What are the values of xdrPtr and xdrLPP when the assert occurs? Can you trace back to where they are allocated?
I would start looking for memory leaks.
im currently writing an error_logger handler and would like to get the stacktrace where the error happend (more precisely: at the place, where error_logger:error* was called). But I cannot use the erlang:get_stacktrace() method, since i'm in a different process.
Does anyone know a way to get a stacktrace here?
Thanks
get_stacktrace() returns "stack back-trace of the last exception". Throw and catch an exception inside error_logger:error() and then you can get the stacktrace.
error() ->
try throw(a) of
_ -> a
catch
_:_ -> io:format("track is ~p~n", erlang:get_stacktrace())
end.
I have not fully debugged it, but I suppose that the error functions simply send a message (fire and forget) to the error logger process, so at the time your handler is called after the message has been received, the sender might be doing something completely different. The message sent might contain the backtrace, but I highly doubt it.