Forum Discussion

TestQA1's avatar
TestQA1
Frequent Contributor
2 years ago
Solved

Advanced Concepts - Test Complete

Hi,

 

I have started to dig more on advanced concepts. I'm not a programming expert but trying to get there. 

I use JavaScript in test complete and my application is written in java.

I need to briefly understand the benefits of the following, would be great if anyone can help!

 

1. Using java bridge - it allows to add java classes. What could be achieved from this?

2. DLL calls - What could be achieved from this?

3. Low-level procedure execution - What could be achieved from this?

 

Thanks in advance!

BDD Tests
Data-Driven Testing
Desktop Testing
Script Tests
  • tristaanogre's avatar
    tristaanogre
    2 years ago

    1) We needed to have the ability to dig into the contents of a PDF file to very text compared to a baseline.  To do this, we found a Java project called PDFBox which, when imported into TestComplete, gave us such options.  This was done via the Java Bridge.
    2) DLL calls allows you to import a DLL developed outside of TestComplete and call methods and utilize properties of the DLL. In a "past life", at a different company, we had a DLL that contained various engines used in the calculation of sales tax on admission tickets.  We used the DLL calls against that engine to test the tax calculations without having to automate the UI of the application.  That's one use of it but the concept is basically the same: using methods of a DLL within your test automation.

    3) As described below, LLPs allow you to simulate Ui actions in a more low-level hardward drive situation.  Same past life, we needed a wat to simulate the swipe of a credit card.  Back in those days (boy, I sound old), credit card magnetic stripe readers could be connected via the keyboard port on a PC and the contents of the stripe would be sent as keyboard events.  So, we used an LLP to simulate that magnetic swipe to make sure that the code of the application recoginized that a swipe occurred rather than a keyed entry of a credit card.

5 Replies

Sort By
  • mikef's avatar
    mikef
    Staff
    2 years ago

    Hi TestQA1 

     

    for 1) and 2) : By creating the bridge to your JVM and providing classes, you can integrate functionality from external Java classes to your TestComplete code editor. Take a look at this page for example : https://support.smartbear.com/testcomplete/docs/testing-with/advanced/using-external-functions/calling-from-java-classes.html

     

    3) Low-level procedures fill the gap where you may need to replicate precisely-timed interactions, like user gestures. Standard on-screen operations will execute as quickly as possible, whereas low-level procedures will take real-time movement timing into account. 

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    2 years ago

    1) We needed to have the ability to dig into the contents of a PDF file to very text compared to a baseline.  To do this, we found a Java project called PDFBox which, when imported into TestComplete, gave us such options.  This was done via the Java Bridge.
    2) DLL calls allows you to import a DLL developed outside of TestComplete and call methods and utilize properties of the DLL. In a "past life", at a different company, we had a DLL that contained various engines used in the calculation of sales tax on admission tickets.  We used the DLL calls against that engine to test the tax calculations without having to automate the UI of the application.  That's one use of it but the concept is basically the same: using methods of a DLL within your test automation.

    3) As described below, LLPs allow you to simulate Ui actions in a more low-level hardward drive situation.  Same past life, we needed a wat to simulate the swipe of a credit card.  Back in those days (boy, I sound old), credit card magnetic stripe readers could be connected via the keyboard port on a PC and the contents of the stripe would be sent as keyboard events.  So, we used an LLP to simulate that magnetic swipe to make sure that the code of the application recoginized that a swipe occurred rather than a keyed entry of a credit card.