negative_zero
New Contributor
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: Sharing test scripts between multiple projects
Thanks Alex, I am still a little bit sad (also surprised) that it isn't possible to have one "test repository" where the actual application-under-test-specific code is located, and then different projects that flesh out the specific use cases in various environments (triggering, testcase selection, report generation etc.). I understand now that the logic of TestComplete is the other way around, and the application-under-test-specific code has to be the top-level layer. I am sure with sufficient planning, a somewhat decent project structure can be designed around that as well. If a SmartBear employee reads this: If the documentation chapter "Managing Projects, Project Suites and Project Items" included some hints as to what TestComplete-specific best practices are, this would be super helpful. Because being complete newbies, that was the location we looked for information prior to setting stuff up. And despite that we apparently did it all wrong. ;-)1.9KViews2likes1CommentRe: Sharing test scripts between multiple projects
Thanks for your reply! With all your information however, I somewhat disagree with your conclusion that you "can share code between projects". It seems to be more of a "you kind of can, but not really" situation. The fact that you used the phrase "duplicating an entire project" synonymously with what my intention was ("using large chunks of a project"), says it all. No one would argue that utilizing "#include" in C, "import" in Java or "using" in .NET is synonymous with "duplicating" anything, even if those are applied to a top level item that depends on the entirety of a different project. I was under the false impression that TestComplete's "//USEUNIT" provides a similar functionality. Seeing that "//USEUNIT" apparently can't do what I thought it could do, I agree that a library style organization of scripts is not effective in TestComplete. I don't particularly like the solution of having one humongous project for everything (otherwise I would have decided for that right away), but it seems to be the only practical one.2KViews0likes3CommentsSharing test scripts between multiple projects
I am testing a WPF application with TestComplete and already have a couple of tests for "manual" use. Now I want to execute these tests in a continuous integration environment, and for that I need different event handling code. In order to get two distinct event handling mechanisms without having to duplicate the tests, I thought it would be a good idea to create a second "Project" within the same "ProjectSuite", and add references to my tests there. For the most part, this seems to be feasible, since I could add references to the name mappings and the test scripts. However so far I see two problems: 1.) I ended up essentially adding every single file from projectA to projectB manually. This is of course now an unstable setup, because changing stuff in projectA in the future now requires projectB to be manually updated. Is there any way to dynamically/automatically add all dependencies that are required due to "//USEUNIT"? 2.) Similar situation for the project settings, in particular the list in "Open Applications" -> "WPF" -> "Composite Controls". I ended up copy/pasting this list from projectA to projectB, which obviously will lead to problems upon future modifications to projectA. Is there any other way to recycle that list other than copy/pasting? I am wondering if I am missing something, or if using a test from different projects is really such an exotic usecase. Because with what I know, all of this feels rather clunky. Maybe there also is a different approach that is more practical (i.e. manual tests and continuous integration tests in the same project, but I am unsure how I would implement the required differences then).Solved2.1KViews0likes5Comments