Forum Discussion

Frits's avatar
Frits
Occasional Contributor
5 years ago

dotNET generic methods

Hi there all! 

 

Currently I am trying to test our software (C# based).

I have "imported" the DLL files through the CLR Bridge and was able to access most of the properties and methods without any problem. However, my only problem is with generic type. So the C# (DLL) code is:

 

public class SomeClass<T> : ISomeClass where T : class
{ public SomeClass(string param1, T param2, SomeType param3);

 } 

 

So I write the TC script in DelphiScript. How do I run such a function?

In C# it would be something like this: var = new SomeClass<T>(param1, param2, param3);

In PowerShell: $var = New-Object 'SomeClass[T]' $param1, $param2, $param3

 

So I have tried a lot of approaches but with no luck.

Most errors are about "cannot create an instance of SomeClass because Type.ContainsGenericParameters is true".

So I tried MakeGenericType, MakeGenericMethod, GetType etc. but with no success. 

 

Could someone maybe help with this? Or clarify if this is simply not possible in TestComplete? :)

 

Kind regards,

Frits 

  • tristaanogre's avatar
    tristaanogre
    5 years ago

    Here's the thing with the CLR bridge.  While it CAN be used for what you're trying to do (import the DLLs and running them through tests), that's not what it was intended for.  The intention is to import DLLs via the CLR bridge for use in building tests against other applications.

     

    What you might want to investigate is https://support.smartbear.com/testcomplete/docs/testing-with/advanced/using-external-functions/calling-from-dll/about.html

     

    Alternatively, perhaps have your developers build a harness or stub of some sort that allows you to make UI calls to exercise the DLL functions.

     

    I've done both in the past with a DLL that we developed to do tax rule calculations for an online webstore.  Worked pretty well.

     

    This is not to say that the CLR bridge won't work for you, but there may be a better solution that might be more geared for your needs.

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    5 years ago

    Here's the thing with the CLR bridge.  While it CAN be used for what you're trying to do (import the DLLs and running them through tests), that's not what it was intended for.  The intention is to import DLLs via the CLR bridge for use in building tests against other applications.

     

    What you might want to investigate is https://support.smartbear.com/testcomplete/docs/testing-with/advanced/using-external-functions/calling-from-dll/about.html

     

    Alternatively, perhaps have your developers build a harness or stub of some sort that allows you to make UI calls to exercise the DLL functions.

     

    I've done both in the past with a DLL that we developed to do tax rule calculations for an online webstore.  Worked pretty well.

     

    This is not to say that the CLR bridge won't work for you, but there may be a better solution that might be more geared for your needs.

    • Frits's avatar
      Frits
      Occasional Contributor
      5 years ago

      Hi tristaanogre, 

       

      Thanks for the explanation! I appreciate your advice.

       

      The only thing I couldn't fully understand is "The intention is to import DLLs via the CLR bridge for use in building tests against other applications." Could you give me an example of this? What do you mean with "other applications"? Like, applications you want to use during development and not during execution? 

       

      Again, thanks for your quick reply!

       

      Kind regards,

      Frits

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        5 years ago

        Not exactly the same, but as an example, there's the PDFBox Java classes.  This is imported via the Java Bridge so that an automated test can be written to validate the contents of a PDF file.  The intention is not to test PDFBox but to test PDFs themselves.

        Out of the box, you can select Browse GAC in the CLR Bridge to select .NET assemblies to be made available within your project, like the Microsoft.Office objects or other similar things.  Again, it's not so you can test the assemblies themselves, but so you can use them to assist in testing tasks.

         

        I know some folks (specifics don't come to mind) who have written .NET assemblies to perform certain tasks so that they don't have to write script code for them.  They can then use those same assemblies in any project without having to import a script file or re-write the code.

        Again, this is not saying that you CAN'T do what you are trying to do, just that there are other ways of achieving the same thing that are more conventional and probably less prone to the difficulties you're attempting.  Keep in mind, TestComplete code is SCRIPT code, not application level code.  So, some things that may work within an application development environment like Visual Studio will probably not work in the world of script code execution.