Forum Discussion

Karthik_gowda's avatar
Karthik_gowda
Occasional Contributor
4 months ago

Choosing programming language

Hi everyone, 
we have a requirement to automate the desktop application that is built on cobol framework , I am in a dilemma to choose the programming language that is either Javascript or python, both have very good user base and community  and I find it easy to implement the framework using python , so if suggestion for using the python over javascript, please suggest. 

 

 

  • AlexKaras's avatar
    AlexKaras
    4 months ago

    Hi,

     

    This is my opinion:

    TestComplete supports four scripting languages: VBScript, DelphiScript, JScript and JavaScript. C#Script and C++Script are essentially JScript with C#/C++-compatible syntax.

    All these scripting languages provide absolutely the same functionality in the meaning of testing with TestComplete (i.e. they behave absolutely identical when looking for a tested UI object and performing actions over it).

    There is a popular idea that automated tests must be created using the same language as the tested application. While this makes sense for unit-testing, I do not remember a case when this was of some value for high-level end-to-end tests. (And you do not do unit testing with TestComplete as this is senseless.)

    Summary: All scripting languages supported by TestComplete has identical testing functionality.

    VBScript has extremely poor and inconvenient error handling functionality. This is the main reason of why I avoid to recommend it.

    DelphiScript was a good option for many years until its error handling was either broken or started to be handled in a different way in TestComplete. Also it might appear to be not easy to port certain code samples from other languages to DelphiScript.

    My biggest concern about Python is that its code structure is based on indents only and it does not provide any means to restore code logic/code flow. I.e. if you stringify Python code, there are no means to restore it to the previous state. The only option is to re-create code logic a-new. One such case was more than enough for me personally to begin avoid Python.

    JScript does not allow to return more than one value from a function and one must apply code workarounds if there is a need to pass some object to a function by value but not by reference. To return more than one value from a function one must return some structure (json for example) and this is not always convenient.

    Summarizing: there is no big difference as for what scripting language to use in your test project in TestComplete, choose whatever you are most comfortable with. Testing functionality will be the same. (But remember, that it is not possible to mix scripting languages - test project can use only one scripting language.)

     

    P.S. Your automation lead is correct about not using NameMapping. Aliases, that are based on NameMapping should be used instead. (Aliases are on top of NameMapping and NameMapping is on top of your tested application and serves as a translation table between physical UI structure of your tested application and logical UI structure that you create using Aliases.) Aliases are already a flavor of Page Object model but with a more extended functionality. Just remember that one should not rely on automatic namemapping functionality in TestComplete. The recommended approach is to manually create convenient, performant and reliable Aliases skeleton of the tested application and then, using this skeleton as a base, use FindXXX methods to search for UI elements that cannot be reliably namemapped.

     

  • rraghvani's avatar
    rraghvani
    Champion Level 3
    4 months ago

    Python and JavaScript are both popular programming languages, but they have different strengths and use cases. Python is commonly used for data analysis, machine learning, and backend web development, while JavaScript is used for both frontend and backend web development. Choosing between them depends on your specific needs and goals

  • Karthik_gowda's avatar
    Karthik_gowda
    Occasional Contributor
    4 months ago

    Thanks for the quick response.
    The goal of this project to automate the desktop application which is developed based on the Cobol framework and the object identification is bit challenging, since the objects has common properties and only way to differentiate is based on the index.
    our automation lead insisting on using the page object model for desktop application and also, we have to use only the scripts and Namemapping is not used for the object identification.
    could you also please suggest any better framework if any and references. 

     

  • Karthik_gowda's avatar
    Karthik_gowda
    Occasional Contributor
    4 months ago

    I'll check that out, however this is one of the object with properties that I am dealing with

     

    • JDR2500's avatar
      JDR2500
      Frequent Contributor
      4 months ago

      Well, I don't know why you wouldn't use name mapping as that would probably solve your problem.  If either the ID or ControlID are static those would be ideal properties for mapping the object.
      If mapping is not an option then in scripts you could find and work with the buttons using FindChild. Look at the examples in this topic:  FindChild Method | TestComplete Documentation (smartbear.com)

      I would probably use WndClass and WndCaption for identification properties with FindChild.  There should never be more than one object at the same level in the object hierarchy with the same WndClass and WndCaption.

      I agree index is not ideal since it could change if the UI in the application changed due to the addition of a new control that would shift all the indexes.  

  • Karthik_gowda's avatar
    Karthik_gowda
    Occasional Contributor
    4 months ago

    All those WndClass and WndCaption have got same value, also all of the window that my earlier screenshot shown have the same parent and it's like a order form where the text/field name  and their actual editable field is identified as different

    • rraghvani's avatar
      rraghvani
      Champion Level 3
      4 months ago

      That has nothing to do with the programming language. 

      TestComplete has identified those objects, with those names, based on what your application exposes. 

    • rraghvani's avatar
      rraghvani
      Champion Level 3
      4 months ago

      ...and the title of the post is "Choosing programming language".

  • Karthik_gowda's avatar
    Karthik_gowda
    Occasional Contributor
    4 months ago

    Thank you, I got that clarity of choosing language. In my comment was referring to usage of name mapping and replying 'JDR2500' post and  also giving a idea of how the application looked like. Thank you once again for your help 

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    4 months ago

    Hi,

     

    This is my opinion:

    TestComplete supports four scripting languages: VBScript, DelphiScript, JScript and JavaScript. C#Script and C++Script are essentially JScript with C#/C++-compatible syntax.

    All these scripting languages provide absolutely the same functionality in the meaning of testing with TestComplete (i.e. they behave absolutely identical when looking for a tested UI object and performing actions over it).

    There is a popular idea that automated tests must be created using the same language as the tested application. While this makes sense for unit-testing, I do not remember a case when this was of some value for high-level end-to-end tests. (And you do not do unit testing with TestComplete as this is senseless.)

    Summary: All scripting languages supported by TestComplete has identical testing functionality.

    VBScript has extremely poor and inconvenient error handling functionality. This is the main reason of why I avoid to recommend it.

    DelphiScript was a good option for many years until its error handling was either broken or started to be handled in a different way in TestComplete. Also it might appear to be not easy to port certain code samples from other languages to DelphiScript.

    My biggest concern about Python is that its code structure is based on indents only and it does not provide any means to restore code logic/code flow. I.e. if you stringify Python code, there are no means to restore it to the previous state. The only option is to re-create code logic a-new. One such case was more than enough for me personally to begin avoid Python.

    JScript does not allow to return more than one value from a function and one must apply code workarounds if there is a need to pass some object to a function by value but not by reference. To return more than one value from a function one must return some structure (json for example) and this is not always convenient.

    Summarizing: there is no big difference as for what scripting language to use in your test project in TestComplete, choose whatever you are most comfortable with. Testing functionality will be the same. (But remember, that it is not possible to mix scripting languages - test project can use only one scripting language.)

     

    P.S. Your automation lead is correct about not using NameMapping. Aliases, that are based on NameMapping should be used instead. (Aliases are on top of NameMapping and NameMapping is on top of your tested application and serves as a translation table between physical UI structure of your tested application and logical UI structure that you create using Aliases.) Aliases are already a flavor of Page Object model but with a more extended functionality. Just remember that one should not rely on automatic namemapping functionality in TestComplete. The recommended approach is to manually create convenient, performant and reliable Aliases skeleton of the tested application and then, using this skeleton as a base, use FindXXX methods to search for UI elements that cannot be reliably namemapped.

     

  • rraghvani's avatar
    rraghvani
    Champion Level 3
    4 months ago

    In this web example, if the button control does not have an ID, it will be identified in Object Spy like so,

    Control with no ID

    However, if the button does have an ID, it will appear like this,

    Control with ID

    TC will attempt to identify the control based on other property values. However, if TC identifies your control as Window("Edit", "", 69), then the Index value is the only unique identifier that TC has identified. 

    The developers of the application need to provide an ID to the control, so that it can be identified by Object Spy like e.g. Window("Edit", "Policy Number", 69).