I understand the recommendation to move to CI/CD build tool for the distributed processing use case. However, another use case is to work with multiple environments/remote computers. For example, executing a test step on one computer and verifying the correct behavior on another app located on another computer (both with TC or TE installed). The new Parallel Environment is only web-based and Selenium grid required. We need remote/multiple functionality for desktop apps.
What is the suggested workaround for that use case? TIA.
> What is the suggested workaround for that use case?
Alas, no suggested workaround except this poll/feature request: https://community.smartbear.com/t5/TestComplete-Feature-Requests/Poll-Do-we-like-to-preserve-the-Syn... (based on Case #00470088)
And yes, I absolutely agree that CI\CD is not a replacement for Network Suite functionality and its Synchronization Points.
> The new Parallel Environment is only web-based and Selenium grid required
and Synchronization Points are not supported thus must be implemented by every script author instead of been provided by the tool as an infrastructure element.
@sonya_m : Just to draw your attention to the fact that some of us consider the decision to deprecate Network Suite functionality to be a potential problem and significant inconvenience.
Though the Network Suite functionality is indeed no longer supported, it will remain available in the product for quite some time before eventually being removed. To start a process of migration to a dedicated CI\CD tool, you can use this article: "Migrating Distributed Tests to CI/CD Systems". It demonstrates how to replicate the Network Suite setup, including synchpoints (https://support.smartbear.com/testcomplete/docs/netsuite-deprecated.html#synch), in Jenkins, but the same should be achievable in every other CI\CD system. Thus, in Azure Pipelines you don't even have to use scripting - the visual Classic mode allows creating several jobs and making them co-dependent. This should address the "multiple environment" case described above.
@exdunepilot, the Parallel object you mentioned was indeed created to make orchestrating cross-platform web test execution easier. However, this object, particularly Parallel.RunTests method is not bound to web testing - it simply starts several helper processes in parallel on the same machine. Since TestComplete tests simulate real user actions, they cannot be executed on the same machine in parallel. But each process can trigger the test on a remote machine. For web testing, we offer remote machines provided by CrossBrowserTesting as Selenium Grid. It's not possible to provide the same service for desktop testing, but one could theoretically create custom logic for remote desktop execution utilizing the Parallel object. However, this would essentially be a clone of Network Suite. So, I'd recommend looking into CI\CD solutions - TestComplete has native integrations with Jenkins and Azure DevOps, but SessionCreator makes it possible to run tests from any tool.
Re: "But each process can trigger the test on a remote machine."
Parallel.RunTests( tests ) does not return a list of processes (doesn't return anything). So how do I trigger the remote tests? And where do I intialize the IP, User, Pwd information in order to connect to the remote machine?
I'm sorry for not being clear - each process can theoretically trigger a test on a remote machine, provided you wrote a script that does it (using cmd, PowerShell, whatever works for establishing a connection to a remote machine). As I mentioned, that would essentially be creating a clone of Network Suite that doesn't seem to be a viable approach.