Community
Participate
Working Groups
Provide error handling for corrupt/incomplete test assets. As a continuation of enhancement 166025 (UC5: http://wiki.eclipse.org/TPTP-Test-Tools-Design-Review-166025-01112008#Core_Use_Cases), provide fall-back error handling for modifications done to test assets outside of the Test Perspective/Test Navigator (e.g. deleting a referenced test asset on the local file system). This error handling mechanism would iterate the workspace when the Test Perspective/Test Navigator is opened to correct any inconsistent references/names. This function would also support UC6 (http://wiki.eclipse.org/TPTP-Test-Tools-Design-Review-166025-01112008#Core_Use_Cases), exporting a subset of test assets and then importing the subset of test assets into a new workspace (e.g. missing test asserts).
Jerome, please provide a sizing.
i am not really sure to understand this bug do they want consistency check ? automatically done or done on refresh ? do they want callback functions in case inconsistency is detected ? updating estimated time to around 2 week (lots of uncertainty margin)
(In reply to comment #2) > i am not really sure to understand this bug > do they want consistency check ? This function would handle the use case where test assets are created/updated/deleted outside of the Test Navigator. For example, on the local file system or in the Package Explorer of the Java perspective. It is required to ensure references between test assets are not corrupted when those referenced test assets are created/updated/deleted outside of the Test Navigator. > automatically done or done on refresh ? Automatically would be best (similar to the Eclipse navigator sensing a resource change on the local file system) although somewhat inefficient. A refresh (or a third alternative, when a reference is requested from the proxy) would require fall-back error handling (e.g. iterating the workspace to find the correct test asset or ask the user to select the correct test asset) as opposed to fixing the reference automatically when the resource change event occurs. > do they want callback functions in case inconsistency is detected ? No. However, we should display the errors as markers in the Problems view so consumers can contribute 'quick fixes'.
No longer required.
Closing.
