Forum Discussion

negative_zero's avatar
negative_zero
New Contributor
6 years ago

Sharing 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 di...
  • AlexKaras's avatar
    AlexKaras
    6 years ago

    Hi,

     

    If I got you right...

     

    > Seeing that "//USEUNIT" apparently can't do what I thought it could do [...]

    Every nation has its customs... :)

    Yes, #include/import directives do not require an entity to be explicitly included into the project. Instead they are utilizing some internal search logic that is usually based on the values from either OS environment (Path/ClassPath/...) or the values stored in the IDE/project file.

    This definitely easies your work as you are not forced to fully qualify required file. But on the other hand it creates a risk that some other file but not expected one is used. And you may be really surprized of why things are working not as expected until you dig into debugging.

     

    One of the possible approaches is to consider the structure of your test code and make it 'linear-dependent'. For example: units of 'utils' type that do not contain any code that is specific to the tested application. Then units of 'helpers' type that contain specific, but generic code. Like selection from the list, button click, waiting for the control, etc. And, finally, the units of 'test' type that contain actual test code.

    With the proper design, the set of 'utils' and 'helpers' units is quite stable. These units can be put on the same level of folders structure on the disk where test projects are located. And then you may reference them from test projects.

    Like this:

    |

    +Libs\

      +Utils\

      +Helpers\

    +Project1\

      + ...

    +Project2\

      +...

     

negative_zero's avatar
negative_zero
New Contributor

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.

AlexKaras's avatar
AlexKaras
Champion Level 3
6 years ago

Hi,

 

If I got you right...

 

> Seeing that "//USEUNIT" apparently can't do what I thought it could do [...]

Every nation has its customs... :)

Yes, #include/import directives do not require an entity to be explicitly included into the project. Instead they are utilizing some internal search logic that is usually based on the values from either OS environment (Path/ClassPath/...) or the values stored in the IDE/project file.

This definitely easies your work as you are not forced to fully qualify required file. But on the other hand it creates a risk that some other file but not expected one is used. And you may be really surprized of why things are working not as expected until you dig into debugging.

 

One of the possible approaches is to consider the structure of your test code and make it 'linear-dependent'. For example: units of 'utils' type that do not contain any code that is specific to the tested application. Then units of 'helpers' type that contain specific, but generic code. Like selection from the list, button click, waiting for the control, etc. And, finally, the units of 'test' type that contain actual test code.

With the proper design, the set of 'utils' and 'helpers' units is quite stable. These units can be put on the same level of folders structure on the disk where test projects are located. And then you may reference them from test projects.

Like this:

|

+Libs\

  +Utils\

  +Helpers\

+Project1\

  + ...

+Project2\

  +...

 

  • negative_zero's avatar
    negative_zero
    New Contributor
    6 years ago

    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. ;-)

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      6 years ago
      negative_zero wrote:

      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. ;-)

      TanyaYatskovska, HKosova: Ladies, could you please note this request?