Introduction

This section lists and answers frequently asked questions about usage of Arjuna.

Although some information might be repeated from elsewhere, it extends the overall documentation coverage by providing new, additional insights and pointers.

Can I Make an Arjuna Test Project depend on another Arjuna Test Project?

Yes.

Method 1 (Basic): ArjunaOption.DEPS_DIR

For simple dependency, where you just want to use the library from another Arjuna Test Project, you can set ArjunaOption.DEPS_DIR in your reference configuration (e.g. project.yaml) or CLI option to point to the directory that contains the project.

For example let’s say “parent” project depends on “child” and “child” is contained in the /abc/def/root/child location. Then:

• You can set deps.dir = /abc/def/root in project.yaml

• You can as well pass --ao deps.dir /abc/def/root in the command line.

The path can also be a relative path. Arjuna will consider it relative to the root of parent Arjuna project.

For example, let’s consider the following directory structre:

• Child project: /abc/def/root/child

• Parent project: /abc/def/xyz/parent

In the above case deps.dir can be passed as ../../root.

Method 2 (Advanced): --link CLI Option

In an Arjuna test project, you typically define many externalized files like configurations, data files, reference files and so on. A simple Python import resolution like Method 1 can not automatically make these available to dependent project. You will need to write quite a bit of complex code to achieve this.

Arjuna provides a feature to make an Arjuna test project linked to one or more other Arjuna test projects and automatically makes their artifacts available to the top project.

To achieve this, you can pass --link CLI option.

For example to link to “linked1” project present at /abc/def/root/linked:

--link /abc/def/root/linked

The path can also be a relative path. Arjuna will consider it relative to the current directory.

For example, let’s consider the following directory structre:

• Linked project: /abc/def/root/linked

• Parent project: /abc/def/xyz/parent

In the above case Linked project path can be passed as root/linked, if current working directory is /abc/def

With this linking, following will happen automatically:

• Configurations

  • project.yaml gets merged.

  • All data confiturations in data.yaml get merged.

  • All environment configurations in envs.yaml get merged.

  • All combinations of data and environment configurations get merged.

• Data References

  • All data references from linked project become available.

  • If there is name conflict, linked project’s references are overriden by parent project.

• Test Resources/Fixtures

  • All test resources from linked project become available.

  • If there is name conflict, linked project’s resources are overriden by parent project.

• DBAuto Files

  • All DBAuto files from linked project become available.

  • If there is name conflict, linked project’s files are overriden by parent project.

You can link multiple projects as well:

--link /abc/def/root/linked1 --link /abc/def/root/linked2 --link /abc/def/root/linked3

In the above case, merging/overriding order is as follows:

• linked2 overrides linked1

• linked3 overrides linked2 and linked1

• parent project overrides linked3, linked2 and linked1

Pay attention to the order of multiple --link switches as it determines the overriding order.

Can I Maintain Local Configuration (.local) Files That Override the Default Configuration Files?

Yes!

Need for Local Config Files

When you work as team then at times you need to create configuration files that are local to your development machine.

There are various reasons to need this feature:

• You are experimenting with a configuration value.

• You have local deployed environments.

• You want to use a temporary user account to test a transient/under-development feature.

and so on.

Supported Local Config Files

Arjuna supports maintaining local versions of all its configuration files. Following table provides the names of the local files and corresponding default files:

Local Config File Names

Local Config File Name	Corresponding Default Config File Name
project.local.yaml	project.yaml
data.local.yaml	data.yaml
envs.local.yaml	envs.yaml
groups.local.yaml	groups.yaml
withx.local.yaml	withx.yaml

What Happens When a Local Config File is Present?

When a local file is present then Arjuna loads this file and IGNORES the default corresponding config file.

Creating local config files is optional and you can create one or more of them as paer your need.

Configuring Version Control To Avoid Check-In of Local Config Files

A suggested practice is to set your version control software to ignore local config files during check-in so that different people in your team can maintain their own versions of these local config files.

For example, if you are using Git, then you can add the following to .gitignore:

**/*.local.*

Can I use an HTTP Proxy with Arjuna where applicable?

Yes. Arjuna allows you to set an HTTP/S Proxy for Web UI Automation and HTTP layer automation.

Setting Proxy across Test Project

You can set a global proxy in project.yaml file. You can also provide the options with --ao switch in CLI.

Following 3 options are the relevant Arjuna options:

• HTTP_PROXY_ENABLED: Enables/Disables proxy. Can be set to True/False. Default is False (disabled proxy).

• HTTP_PROXY_HOST: Host/IP of proxy. Default is localhost.

• HTTP_PROXY_PORT: Network port of proxy. Default is 8080.

Setting Proxy for a Particular HTTP Service

Rather than a global proxy setting, which applies to all Web GUI Automation as well as HTTP Automation, you can also set the proxy for a particular HttpService as follows:

# Direct Session
service = Http.service(proxy=Http.proxy('proxyhost', 9000))

# From ouathsession
service = ouathservice.create_new_service("https://someurl.com", proxy=Http.proxy('proxyhost', 9000))