Closed reprogrammer closed 13 years ago
@vazexqi:
All of the wrong navigation histories belong to cancelled refactorings that are not invoked by Quick Assist, and some of them are captured by the most recent version of CodingSpectator (v1.0.0.201107172337). We need to investigate this problem further and find the root cause of it.
@rajkuma1: The classes org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog
and org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2
are two of the main classes that CodingSpectator instruments to record the navigation histories.
@rajkuma1, @reprogrammer
Problem: We capture when the user explicitly presses one of the buttons of the wizard e.g. Next, Previous, Cancel, etc but not when the user closes the dialog by hitting ESC or by clicking 'X' on the window.
Steps to reproduce:
This failure to capture CLOSE_EVENTs means that we don't know how long the user has been starring at the dialog. However, the status of it being a canceled refactoring is still correct. So we can still correctly use this information in our analysis.
Test extractmethod.T07
failed frequently on my laptop because it didn't generate some of the log files. I need to repeat the test on another machine to see if the problem persists.
Sometimes, the automated GUI tests fail even on my desktop machine because the actual logs are missing. I believe this problem is due to the timing issues of tests. However, I expected that the use of wait statements instead of sleep statements would fix this issue, but, apparently the tests are still fragile (See issue #226).
Every navigation history should contain at least two items: the invocation of the refactoring and the termination of it. However, I found 35 refactorings whose navigation history just captures the beginning of the refactoring. I found these refactorings while trying to compute the duration of time spent on configuring each refactoring.
I executed the following query against our database of events:
The above query produced the following results.