Community
Participate
Working Groups
Hi, the refactoring "Move to External Project" is prone to break test cases without issuing a warning. Even in those cases where the situation can be fixed later, this may lead to loss of Data Sets. E.g. consider three projects P_A, P_B and P_C where P_A uses both P_B and P_C, but the latter two are unrelated. Have a test case TC_a in project P_A reference a test case TC_b of project P_B. After moving the test case TC_a to project P_C, which is possible without warning, it cannot find test case TC_b any more and at this point all Data Sets of this call are lost. As Alex mentioned in the Forum (http://www.eclipse.org/forums/index.php/mv/msg/489875/1066664/#msg_1066664) there is currently no easy way to check this kind of dependancy in more complex situations. Furthermore, the move described above will break a project P_D that includes only project P_A and references TC_a (but is not 'visible' from the point of view of the currently opened project P_A). Hence, it would be great if those projects were also checked that are not currently included but present in the database. Similar to this last point, including the projects solely present in the database (both their test cases and test suits) would also be a vast improvement of the "Show Where Used" search functionality.
Reading this, the gist I get is that it would be desirable to : 1) perform a database-wide "show where used" (i.e. where is this Test Case used in other projects in the database, possibly with some kind of hierarchical display). Based on this information, it would be easier to see whether Test Cases can be deleted / moved. The reverse case : show specification, is already possible -> If P1 reuses the project P2 which in turn reuses P3, then any Test Case that was created in P1 but uses Test Cases from P2 and / or P3 can be followed back to its roots using repeated "Show where used". By definition, to be able to use a Test Case, it has to be (referenced) in the current main project. 2) However, for the move, it may be useful to have the hint that the planned target project does not reference the correct projects to make the move possible. 1) and 2) could well be different enhancements. I'm not sure about the possibility / feasibility / effort involved with either. Eric - if you could tell me if I've got the general details correct as you also understand them, that would be good. @Markus - I'm assigning this to you - can you add any information on the feasibility / effort for this? If not, or if not at the moment, then ping back to inbox with a short comment.
Hi Alex, yes, I can confirm that your points address my problems as I understand them.
*** Bug 412570 has been marked as a duplicate of this bug. ***
Thank you for your confirmation Eric. I'll wait on Markus' feedback one way or the other.
Both enhancements are definitely doable - a rough estimation: 1) ~1 day of work for retrieving these information (hierarchical result: <project name and version>/<name of the re-using node>) and display them. In addition to this it would be very useful to widen out where / when this action should be invokable (e.g. even without a project is currently loaded in the ITE) and how the results should be traversable (e.g. open the other projects / nodes automatically) 2) ~1 1/2 day of work to display these information in case of a move being performed + warning; this involves a "fully transitional dependency usage analysis" for the node (and it's transitive references through projects). Also keep in mind that the projects major and minor version have to be taken into account for such an analysis.
ad 1) As a user, I would expect the locations in other projects to be displayed as part of the result of the existing action "Show where used (F7)". Hence, I would not necessarily consider it a new action; or, if it is to be a new action, I would expect it to behave just like said existing action.
I'm not sure that I agree that the locations in other projects should be displayed by default - I can imagine that it would cause some confusion. I'd prefer to see it as a filter in the search result view so that it can be displayed / not displayed as the user desires.
