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\

      +...

     

tristaanogre's avatar
tristaanogre
Esteemed Contributor

There is no way, currently, of adding all dependencies to every project.  However, completely duplicating a project JUST for an event handler....  any developer would tell you that you don't write two different programs for two different environments, you just modify the existing program to be "smart" and detect the environment.  So, in your case, what I would do is build in some sort of "Detection" to your event handler that it would recognize whether or not it's being called from your CI environment.  If it is, handle the event one way.  If it isn't, do it another way.

 

There are a number of techniques you could use for this.  One would be to parse the commandline used for running TestComplete/TestExecute to detect whether or not it's being run with commandline switches (a pretty clear indicator that you're running from a CI).  

Another would be to have some sort of variable that updates on the project level (Project.Variables) that would contain a value that changes depending upon how the test is run and have the event handler look for that.   

 

This would be a LOT more efficient than completely duplicating a project.

 

You CAN share code between projects... that's a common practice.  But duplicating an entire project?  That's an exotic case that, honestly, I think should be avoided.

negative_zero's avatar
negative_zero
New Contributor
6 years ago

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?