jyurkiw_bmux's avatar
jyurkiw_bmux
New Contributor
9 months ago
Status:
New Idea

Python PIP support

Give us some kind of interface for the pip installed in the TestComplete python environment. I'm not sure how or why you thought that nobody would ever need to install external packages to write tests, but that's not how anything works.

I've got a medical instrument that runs MongoDB, and I need to access that database to do a variety of things such as...

  • Environmental setup (need to set up collections so that the UI looks a certain way and everything is where I expect it to be)
  • Test setup (need to insert documents to make changes to and remove extraneous information so the entries I need for my tests to run are where I expect them to be in the UI)
  • Test teardown (need to clean up after myself)
  • Test sanitization (need to clean up after myself)
  • Assertions (the UI is data-driven and the data is in the DB)
  • etc.

Additionally, because we have security to worry about, AND we use a client-server design, I need to use an SSH Tunnel to access the MongoDBs installed on slave machines to test and make sure that data is being written correctly across multiple points of possible failure (the alternative is to open the firewalls on the slave machines, but there are multiple people who want me to figure out a different way).

I cannot write these tests without installing additional python libraries. Help me install additional libraries into the TestComplete python environment.

I mean, the TestComplete python directories aren't even writable by a system administrator without editing the security settings. That alone means you have to do it for me.

  • jyurkiw_bmux's avatar
    jyurkiw_bmux
    New Contributor
    9 months ago

    Okay, I think part of the problem is that TestComplete juggles two of its own environments, and then doesn't tell you which one its going to use when it does things. For example, if you run recorded UI tests, it uses one of the locked down environments in the TestComplete/(x64 optional depending on OS)/bin/Extensions/Python/Python311/Lib directory.

    However, if you try to run a test through a UnitTesting/PyUnit testing unit in your project, it's actually going to use one of your system's default execution environments.

    As far as I can tell, none of this is configurable in TestComplete except for x86 vs x64 with recorded UI tests, and that's simply based on what OS you're running.

    Examples of what I mean:

    • If I create a function in a script unit and right-click and select "run this routine", it's going to run it using one of the locked down environments (x64 in my case) through TestComplete.exe.
    • If I create a UnitTest directory, then add a pyUnit test and run it, it's going to use my system's default python environment (and it's not going to tell me).

    At the very least this is confusing and cannot be configured (our product's execution environment is built on top of Anaconda, and my laptop has roughly 9 python execution environments on it, not counting the two that TestComplete creates). As it stands, pyUnit runs are using environment #3 on my system...out of 9...with no reason given and no apparent way I can find to tell TestComplete which one to use.

    Honestly, I would prefer to either define individual project and subproject virtual environments (that would be the best outcome, by far), or at least be able to tell testcomplete which system env to use when running unit tests through an entry in one of the setting menus (assuming not running them through the TestComplete exe isn't a bug in the first place).

    At the very least, at that point I wouldn't have to worry about the execution environment randomly changing whenever I need to make a new system environment with anaconda.