There is some sort of problem in JFCTestCase acquire() method.
If I am understanding this correctly, the below code within the method tries to acquire the lock on the m_lock variable. If it's already locked, it can't not be acquired and falls out of the method. If it is not locked, it checks the m_pausingAWT flag and if true, calls m_lock.wait(), if false, calls it with a timeout period.
The problem is, the m_lock.wait() waits forever! It never seems to give up the lock and therefore my tests always pause and never continue.
Sadly, I have no clue why, but the developers of jfcUnit don't explain a large portion of the inner working methods very well, if at all, and thus it's difficult to figure out exactly why this is happening. I am not a thread expert, I understand them to a degree, but I can't fix this cause I have no clue why it's locking. My only fix is to comment out the m_lock.wait() call which then allows things to work. However, this may be why my tests can't seem to find the menus within popup menus from the menubar... I am not entirely sure.
If anybody (Kevin Wilson I think is probably the only one that might be able to explain this), could take a crack at it, please do and let me know, or modify the source and send it to me. Another thought is to just put a timeout in the first one as well, so that it at lest times out.
Is there some code in my tests that I need to include to release it? Sadly the examples show little use of how this should work, and thus far even though apparently hundreds of companies use jfcUnit, nobody has put any sort of examples on the recent releases on complex testing. It seems everybody only tests login screens I guess?
There are a ton of problems with jfcUnit. record/playback is inconsistent, as is manual coded tests during playback. Sometimes they work, sometimes they dont. I have especially noticed that trying to find menu items in popup menus seems to easily not owrk if you accidently bump your mouse the slightest bit, causing the mouse on screen to fall off the menu and it closes. There should be some way to automatically not listen to incoming events when a test is running except for a key like ESC to stop it. I am surprised you can just override during a test and mess the test up. If you shake your desk by bumping your knee into it (I am tall), you mouse moves a bit and a test can fail. That's not a good thing. I am looking to add a way to block all events during playback so that nothing can distrurb the test. This would be an optional flag to turn on/off, but it should be part of the framework.
synchronized (m_lock)
{
try
{
if (m_pausingAWT)
{
m_lock.wait();
}
else
{
m_lock.wait(m_lockWait);
}
}
catch (ExitException exe)
{
; // don't do anything here
}
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most of the enterClick type methods are not supported in the setup sections of code. My guess is that the test case is not started. Thus the release mechanism is not queued on the AWT Event queue.
In 3.0 I am hoping to address the shortcommings of submitting events from the setUp/tearDown methods. I also hope to compartmentalize and separate the test framework from the event framework.
Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is some sort of problem in JFCTestCase acquire() method.
If I am understanding this correctly, the below code within the method tries to acquire the lock on the m_lock variable. If it's already locked, it can't not be acquired and falls out of the method. If it is not locked, it checks the m_pausingAWT flag and if true, calls m_lock.wait(), if false, calls it with a timeout period.
The problem is, the m_lock.wait() waits forever! It never seems to give up the lock and therefore my tests always pause and never continue.
Sadly, I have no clue why, but the developers of jfcUnit don't explain a large portion of the inner working methods very well, if at all, and thus it's difficult to figure out exactly why this is happening. I am not a thread expert, I understand them to a degree, but I can't fix this cause I have no clue why it's locking. My only fix is to comment out the m_lock.wait() call which then allows things to work. However, this may be why my tests can't seem to find the menus within popup menus from the menubar... I am not entirely sure.
If anybody (Kevin Wilson I think is probably the only one that might be able to explain this), could take a crack at it, please do and let me know, or modify the source and send it to me. Another thought is to just put a timeout in the first one as well, so that it at lest times out.
Is there some code in my tests that I need to include to release it? Sadly the examples show little use of how this should work, and thus far even though apparently hundreds of companies use jfcUnit, nobody has put any sort of examples on the recent releases on complex testing. It seems everybody only tests login screens I guess?
There are a ton of problems with jfcUnit. record/playback is inconsistent, as is manual coded tests during playback. Sometimes they work, sometimes they dont. I have especially noticed that trying to find menu items in popup menus seems to easily not owrk if you accidently bump your mouse the slightest bit, causing the mouse on screen to fall off the menu and it closes. There should be some way to automatically not listen to incoming events when a test is running except for a key like ESC to stop it. I am surprised you can just override during a test and mess the test up. If you shake your desk by bumping your knee into it (I am tall), you mouse moves a bit and a test can fail. That's not a good thing. I am looking to add a way to block all events during playback so that nothing can distrurb the test. This would be an optional flag to turn on/off, but it should be part of the framework.
synchronized (m_lock)
{
try
{
if (m_pausingAWT)
{
m_lock.wait();
}
else
{
m_lock.wait(m_lockWait);
}
}
catch (ExitException exe)
{
; // don't do anything here
}
}
Most of the enterClick type methods are not supported in the setup sections of code. My guess is that the test case is not started. Thus the release mechanism is not queued on the AWT Event queue.
In 3.0 I am hoping to address the shortcommings of submitting events from the setUp/tearDown methods. I also hope to compartmentalize and separate the test framework from the event framework.
Kevin