Community
Participate
Working Groups
Deleting the .testsuite file should also delete any associated files with the test suite. Problem: -------- - Create a new HTTP Recorder - Delete the .testsuite file from the 'Test Navigator' view of the 'Test' perspective - Switch to the 'Navigator' view - Notice that the .rec and .recmodel files of the HTTP Recorder are still there If there is a reason for keeping these files then the user should be at least prompted whether he/she wants to also delete all the associated files with the test suite.
This issue is not specific to HTTP, but common to everything in Test
Adding Hendra Suwanda to the CC list because Navid has gone back to school. If you have any questions about these defects then please ask Hendra.
Reassign to Jerome for tptp 4.2. in accordance with discussion in Test project meeting 12/12/2005.
Updating target to future as requested by the PMC. Enhancements are targeted to future if not in plan for the current release.
Jerome, wouldn't this request be handled under the delete use case for 166025? The exception would be the .rec and .recmodel files since there is no direct link from the generated test suite. Any ideas?
this is not as simple as it seems.... in fact, testsuites are generated from .rec or .recmodel files so, a .rec can generate several testsuite. and if the user make an error by deleting things inside a testsuite that can not be created manually (as "windows" element in citrix testsuite), he have no way to recreate them outside re-generating the testsuite so, on my opinion, we can not delete the rec and recmodel files when we delete a testsuite on the other side, we could make a "owner" relationship from rec to testsuite, so that deleteting a rec file give the user the ability to delete the testsuite (disabled by default) doing this could be done quite easily : i just have to check if rec/recmodel file have their own proxy kind. if yes, we just have to define two relationship (recToTestsuite and testsuiteToRec) with the existing extension point, with the "own" flag corectly setted, and the work is done we should discuss on this topic on next meeting....
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
