Python __getprop__ fails

[hhowe]

I've added the "requests" package to the ...\TestComplete 12\x64\Bin\Extensions\Python\Python36\Lib folder.

This code works beautifully to return the proper response using the Python installed by TestComplete (Python 3.6 with TestComplete 12.42):

import requests
baseURL = 'https://jira.mycompany.com'
URL = baseURL + '/rest/zapi/latest/util/project-list'
r = requests.get(URL, auth=('MyUsername', 'MyPassword'), verify="c:\shared\certs")
print (r.text)

This code does not work from within a Python project in TestComplete (running the x64 copy):

import requests
def TestAPICall():
   baseURL = 'https://jira.mycompany.com'
   URL = baseURL + '/rest/zapi/latest/util/project-list'
   r = requests.__getprop__('get', URL, auth=('MyUsername', 'MyPassword'), verify="c:\shared\certs")
   Log.Message(r.text)

The latter returns a Python runtime error:
   AttributeError: module 'requests' has no attribute '__getprop__'

I've also tried:

   r = requests.get(URL, auth=('MyUsername', 'MyPassword'), verify="c:\shared\certs")

which returns:

   AttributeError: module 'requests' has no attribute 'get'

What am I missing?

Thanks,

Heath

[tristaanogre]

__getprop__ only applies to objects from your AUT, not to the requests object.

Just as an experiment, what happens if you add the requests package to the ...\TestComplete 12\Bin\Extensions\Python\Python36\Lib folder as well.  Does that work better?

[hhowe]

Thanks, Robert,

That makes sense about the __getprop__ only being for tested objects' properties. It was a punt...and is always an afterthought/fix for me when the standard Python format fails on me. 🙂

I did copy the requests package to the x86 path, stopped and restarted the x64 version of TestComplete (just to be certain!) and get the same error on the "get" (direct requests.get, not requests.__getprop__). I also ran the x86 version of TestComplete and get the same error. It is finding the package, because I get a different error (ModuleNotFoundError: No module named 'requests') if the package is not in the right path.

Good thoughts/info, though. Much appreciated. Other ideas??

[tristaanogre]

Can you inspect the "requests" object?  By that, I mean drop a break point in your test complete code and use the Evaluation tool to see what "requests" actually has in the way of properties, methods, fields, etc.  It could be that "get" might be an overloaded function in which case TestComplete might actually see get1, get2, get3, etc.  

[hhowe]

Another good suggestion and I've done that earlier in the week, or at least explored the Local var values of a "requests" object (defined as "r" in the attached). I see nothing that looks like a "get" of any kind at the first or second level.

[tristaanogre]

Actually, I was thinking of using the button highlighted below

This will give you a view of the object more like what you see in ObjectBrowser that you can explore.  What you see in your screenshot are the properties... get seems like it's more a method/function than a property.  The Evaluation dialog will expose a bit more.

[hhowe]

I don't often use that, but was seeing the same things under Inspect (and no methods). If there's other functionality within Evaluate I should explore for this issue, please enlighten me. Screenshots attached of that inspection of the requests object.

Thanks!

Heath

[tristaanogre]

See those ellipses buttons besides a few of the objects?  You might have to start drilling down and looking.

Beyond that, I'm not going to be much more help.  The "get" attribute/method you are calling off of "requests" might be translated differently if you're doing straight-up python.  TestComplete has it's own engine it runs so if the regular Python intepreter is making some assumptions, it could be buried in there somewhere.

[tristaanogre · Accepted solution]

An alternative... rather than going third party, have you looked into using TestComplete's own aqHTTP object for sending Get and Post requests?

https://support.smartbear.com/testcomplete/docs/reference/program-objects/aqhttp/index.html

[hhowe]

That's awesome. I have not used aqHTTP before. That may be just the juice I need to fuel my flight. I'll give it a shot next week. Thanks!