Errors connected with infinite loops of view events are the topic of this question. Such loops don't throw StackOverflowError, because are executed very frequently, but not recursively. An example of that code error could be invalidate() call inside onDraw of custom view.
By default AndroidJUnit4 waits for app idle after starting a test activity and then performs verifications. But in case of infinite lifecycle loop idle won't be achieved and test will fail with error java.lang.RuntimeException: Could not launch intent Intent within 45 seconds. Perhaps the main thread has not gone idle within a reasonable amount of time?
Such error isn't so declarative and test have to wait for it so long.
For example,
I should test onLayoutChildren method of LayoutManager. By default in case properly implementation this method is executed two or three times after start and that's all. And this test is passed
verify(spy, atMost(3)).onLayoutChildren(any(RecyclerView.Recycler.class), any(RecyclerView.State.class)), where spy is a spy of LayoutManager. A behaviour could be corrupted and onLayoutChildren goes to infinite loop. In case of error under test it stucks.
What i am trying to achive. Possible variant is run test & application for some time (like 500ms or so) then break the app and perform verifications after that. Without any connection to idle
Related
I am making a javafx application that simulates a robot vacuum.
I want it to be automated so it would vacuum the environment by itself.
I need to insert a delay so a human can see the steps the vacuum is taking as it traverses the environment.
So far all the delay methods I have tested crash my program if they are inside a while loop.
If I put it outside the while and just click a button for the next step, everything works fine.
It also works fine if I set the delay to really short time, like 1 ms.
Any ideas of why this is happening?
Any application that executes a set of instructions for a while (is busy) and cannot respond to user input or system events is "seen" by Windows as "not responding" and when you try to interact with a "not responding" program, Windows will tell you it crashed.
The problem, you see, is that you try to delay interface updates with a while loop, and that makes your program execute something for a while and while is busy executing your loop it cannot respond to system or user events.
If you want to make delayed updates, use multithreading. Your while loop is blocking the main thread which is also responsible for rendering and taking any input, so you cannot block this thread. Create another thread and share state (eg. use observer pattern). And then you can execute TimeUnit's sleep() in this helper thread and it won't make your app "crash".
In JMeter,
I'm creating a test plan
In which I need to set a condition
(if the fail count rate is high than success, then I want my test to stop)
Tried :
Auto-stop listener but its useful if we specify error rate %
Tried bean shell post-processor but unsuccessful.
if (!prev.isSuccessful()) {
prev.setStopThread(true);
}
Any ideas much appreciated.! thanks in advance.!
By calling setStopThread you are "asking" JMeter to attempt to stop current thread only, the correct method would be prev.setStopTest(true). Again, if you call this method JMeter will "ask" threads to stop, if you want JMeter terminate in less graceful manner you can go for prev.setStopTestNow(true) method (you can get more failures this way as samplers will be abnormally terminated)
And finally you can call System.exit(1) method which will immediately terminate the whole JVM.
Be aware that since JMeter 3.1 it is recommended to use JSR223 Test Elements and Groovy language for scripting consider migrating from Beanshell to Groovy on next available opportunity.
I think that you can use a test-action sampler, combined with an if-controller and an action stop:
Create an 'If Controller' and set your condition.
Create a 'Test Action' inside where your action is 'stop'.
I have a custom controller type which runs it's own specific test fragments. The important thing to note is that these fragments contain Transaction Controllers, which contain gaussian timers simulating wait times of up to 5 minutes.
The tests I am running are data driven, and should be runnable for a varying length of time. To specify the runtime of a test I have been using the "Duration" option on the Thread Group scheduler.
In the event were a test has ran beyond its duration, I've noticed that when these timer fragments are in use, the test is delayed and cannot end until the transaction (or at least the timer) has been complete. The other timings and samplers recorded seem to be unaffected, however the runtime of the test is impacted.
I'd like to solve this issue without having to rely on the user manually killing a test when it has reached it's duration. Is there any option within JMeter to kill or interrupt any type of running thread when a duration has been reached?
As per my understanding with Jmeter, there is no element which can stop the running test on reaching specific duration.
However, an element named 'Test Action' can be used to Pause/Stop/Stop Now actions on your test during run time and this element can be used under 'If Controller' element so that you can set the condition in this element to stop the thread.
Although JMeter provides various head-on elements to handle different conditions but in rare cases where existing elements could not provide direct solution to the problem then JMeter experts in any software testing company uses multiple elements with child-parent hierarchy to handle the condition [as used above with Test Action & If Controller elements]
I believe this has to do with stop test vs shutdown. When a test reaches its duration, it will issue a stop test, at which point any timer will finish, the request will happen, then the thread stops. This is why manually shutting it down works- shutdown doesn't respect timers, etc.
I don't think there's a way to set duration to use shutdown rather than stop. One thing you might try is multiple, smaller timers, and see if it still waits for all of them.
I have an application that loads a series of large images on startup. This is a Processing application, so most things run on the single main animation thread, and it's using Processing's OpenGL renderer.
EDIT: the RuntimeException is thrown when some process within JOGL takes > 5 seconds. Making it back up the stack to subsequent loadImage() calls means the RuntimeException is avoided. I'm not clear yet how to repro this and so haven't found a way around it save the ugly try-catch + reflection workaround here.
The image loads sometimes take longer than 5 seconds, and when they do, JOGL throws a RuntimeException from within RecursiveLockImpl01Unfairish.lock(). My understanding is that RecursiveLockImpl01Unfairish.lock() complains if the main GL animation thread halts execution for > 5 seconds.
Is there a simple fix for this? I could shift the image loads to a different thread and reshuffle my init sequence to be more asynchronous, but that's a lot of work for something that happens only once, on application init, at a time when the application has plenty of time to start up regardless.
(Note: this is for an installation, no one will be present or trying to use the application when it first launches in the morning, so a delay of many seconds on init is not a problem.)
I want to test some code that relies on a network transmission. The code makes a request and supplies a callback - when the request completes, the callback is fired. I'd like to mock out the network transmission, and use Thread.sleep to simulate some latency... but of course that will make the whole test pause.
So far I've been making new threads and using CountDownLatches throughout the test to stop the test from ending before the callback is fired. My mock network object makes a new thread, sleeps on that thread, and then fires the callback. That's actually working pretty well, but the problem is that any assertion errors in the callback are not reported to the original junit thread - instead, I'm getting exception text on the console, where it's much harder to understand and use.
I'm hoping there's either:
A way to pipe assertEquals output from spawned threads into the main JUnit output collector, or
A totally different and better way to test threaded code in JUnit, or
Some way to simulate asynchronous code in a single thread
Thanks for any ideas!
When I had to implement asynchronous mechanism similar to yours I created abstract class AsyncTestCase that holds test error and provides special method waitForCallback(). When asynchronous task finds error in expected results it puts the error into this variable. The setter calls notify() on object that is used by waitForCallback(). So, when callback arrives it immediately causes test to awake. Then I can call all assertions including that one that was stored by asynchronous task.
And do not forget to put timeout on your tests to prevent them from sleeping forever:
#Test(timeout=10000)
public void mytest() {
callAsyncTask();
waitForAsyncTask(); // from base class
assertAsyncTaskResult(); // from base class
}