This is a feature return request and a follow-up to the case #00126077.
Consider the following scenario: -- Create or open existing test project with two test items using the local path notation (c:\path\project); -- Make sure that both test items are enabled (checked); -- Close test project and open it in the shared mode using UNC path notation (\\machine\c$\path\project); -- Accept default suggested settings; -- Disable (un-check) one of test items and save all changes; -- Close the project and re-open it using the local path notation; -- Note that one test item is disabled while it is expected that both test items to be enabled. It is expected that all project per-machine settings, as well as the files opened in the workspace, are saved in the corresponding [machine]\project\project.mds.tcLS file like it was in previous versions of TestComplete.
Response from Support:
The current philosophy is using the SCC systems rather than the network mode. The network mode is preserved only as a backward compatibility measure.
Arguments for functionality return:
a) The background philosophy for all our test projects is "single code base with environment-specific settings". Which means that tests are executed from the single network resource but rely on different settings to be properly set up. The state of Test Items tree is one of such settings (e.g. to execute some tests on one system but skip them on another). Likewise the value of the persistent project variables. Yes, the above can obviously be implemented in code (by checking OS version, machine name, etc.), but I see very little sense to increase test code complexity with the functionality that is not directly related to the actual test. This feature was *so* useful and handy...
b) One of the TestComplete advantages that I always mentioned everywhere, is that, unlike the tools like Selenium, TestComplete provides not only the functionality, but also the infrastructure (convenient log, project variables, test items, network suite, DDT, etc.) that supports the functionality and makes it possible for the user to do his/her primary job (i.e. test functionality of the AUT), but not spend time to implement this or that functionality (like connecting third-party logs to Selenium) that has no direct relation to his/her primary responsibilities. The strength of this argument is seriously lowered now...
I would like to ask for restoring the functionality to have settings for the project opened in the shared mode to be per-machine, but not global.