Click one of the radio-buttons to choose the possible target.:
Module name – by using a Python module name and a test class instance.
Script path – by using a path to a Python file.
Custom – by using an arbitrary combination of paths, modules, and test class instances.
Depending on the selected Target type, you can specify the following values:
Path to the test file, for example, /Users/jetbrains/Car/test_car.py. You can type in the path or click the button to locate the file in the project structure.
Name of the module in your project, for example, my_tests. You can type in the module name, search the target module by its name, or locate it in the project structure.
Custom combination of modules, scripts, and Flask class instances, for example, my_tests.test_car.TestClass, where:
my_test – the module name
test_car – the target file in the module
TestClass – the Flask class instance in access.
In this text field, specify the pattern that describes all the test in the required location.
In this text field, specify the additional framework-specific arguments to be passed to the test as-is, for example --some-argument=some-value.
Click the browse button, or press Shift+Enter to specify the desired set of environment variables in the Environment Variables dialog box. To create a new variable, click , and type the desired name and value.
In this field, specify the string to be passed to the interpreter. If necessary, click , and type the string in the editor.
Specify a directory to be used by the running task.
When a default run/debug configuration is created by the keyboard shortcut Ctrl+Shift+F10, or by choosing Run on the context menu of a script, the working directory is the one that contains the executable script. This directory may differ from the project directory.
When this field is left blank, the bin directory of the IntelliJ IDEA installation will be used.
This field appears, if a remote interpreter has been selected in the field Python interpreter. Click the browse button to define the required mappings between the local and remote paths. In the Edit Path Mappings dialog box, use / buttons to create new mappings, or delete the selected ones.
Add content roots to PYTHONPATH
Select this check box to add all content roots of your project to the environment variable PYTHONPATH;
Add source roots to PYTHONPATH
Select this check box to add all source roots of your project to the environment variable PYTHONPATH;
Docker container settings
Click to open the dialog and specify the following settings:
Disable networking: select this checkbox to have the networking disabled. This corresponds to --net="none", which means that inside a container the external network resources are not available.
Network mode: corresponds to the other values of the option --net.
bridge is the default value. An IP address will be allocated for container on the bridge’s network and traffic will be routed though this bridge to the container. Containers can communicate via their IP addresses by default. To communicate by name, they must be linked.
host: use the host's network stack inside the container.
container:<name|id>: use the network stack of another container, specified via its name or id.
Links: Use this section to link the container to be created with the other containers. This is applicable to Network mode = bridge and corresponds to the --link option.
Publish all ports: Expose all container ports to the host. This corresponds to the option --publish-all.
Port bindings: Specify the list of port bindings. Similar to using the -p option with docker run.
Extra hosts: This corresponds to the --add-host option. Refer to the page Managing /etc/hosts for details.
Volume bindings: Use this field to specify the bindings between the special folders-volumes and the folders of the computer, where the Docker daemon runs. This corresponds to the -v option. See Managing data in containers for details.
Environment variables: Use this field to specify the list of environment variables and their values. This corresponds to the -e option. Refer to the page ENV (environment variables) for details.
Click to expand the tables. Click , , or to make up the lists.
Use this tab to specify which log files generated while running or debugging should be displayed in the console, that is, on the dedicated tabs of the Run or Debug tool window.
Click this button to remove the selected log entry from the list.
When you edit a run configuration (but not a run configuration template), you can specify the following options for it:
In this text box, specify the name for the run/debug configuration. The name will help you identify the created configuration when you choose to edit it later, or when you invoke it, for example, from the Run popup (Shift+Alt+F10).
Select this checkbox to make the run/debug configuration available to other team members.
If the directory-based project format is used, the settings for a run/debug configuration are stored in a separate .xml file in the .idea\runConfigurations folder if the run/debug configuration is shared, or in the .idea\workspace.xml file otherwise.
If the file-based format is used, the settings are stored in the .ipr file for shared configurations, or in the .iws file otherwise.
Allow running in parallel
When disabled, every time a new run/debug configuration is launched, IntelliJ IDEA checks the presence of the other instances of the same run/debug configuration, and displays a confirmation dialog box. If you click OK in the confirmation dialog box, the first instance of the runner will be stopped, and the next one will take its place.
This makes sense when the usage of certain resources can cause conflicts, or when launching two run/debug configurations of the same type consumes too much of the CPU and memory resources.
If this checkbox is selected, it is possible to launch as many instances of the run/debug configuration as required. So doing, each runner will start in its own tab of the Run Tool Window or Debug Tool Window.
The tree view of run/debug configurations has a toolbar that helps you manage configurations available in your project as well as adjust default configurations templates.
Create a run/debug configuration.
Delete the selected run/debug configuration. Note that you cannot delete default configurations.
Create a copy of the selected run/debug configuration. Note that you create copies of default configurations.
View and edit the default template for the selected run/debug configuration. The templates are used for newly created configurations.
Move the selected run/debug configuration up and down in the list.
The order of configurations in the list defines the order, in which the configurations appear when you choose a run/debug configuration.
Default templates of run/debug configurations are always sorted alphabetically.
To create a folder, select the configurations within a category, click , and specify the folder name. If only a category is in focus, an empty folder is created.
Then, to move a configuration into a folder, between the folders or out of a folder, use drag-and-drop or and buttons.
To remove grouping, select a folder and click .
Click this button to sort configurations in the alphabetical order.
Under the Templates node in the tree view of run configurations, you can select a run configuration template and edit its default settings. This will not affect the configurations that are already created, but will be used as defaults when creating new configurations of the corresponding type.
When you select the Templates node itself, you will be able to adjust general settings that apply to all run/debug configurations:
Configurations available in Run Dashboard
In this section you can create a list of run configurations available in the Run Dashboard — a tool window that helps you execute and manage multiple run/debug configurations.
Note that the dashboard will only display the configuration types for which you have created one ore more configurations. Thus, if you add a configuration type for which no configurations exist in the project, this type will not be displayed on the dashboard until you create a configuration of this type.
Confirm rerun with process termination
The behavior of this checkbox depends on whether the Single instance only option is selected for a particular run/debug configuration.
If this checkbox is selected, in case of a single instance, launching a new process (for example, by clicking on the main toolbar) while another process is still running, results in showing a dialog box prompting to terminate the current process before launching a new one.
If this checkbox is not selected (or in case of multiple instances), IntelliJ IDEA starts the new process silently.
Temporary configurations limit
Specify the maximum number of temporary configurations to be stored and shown in the Select Run/Debug Configuration drop-down list.
Before Launch options
In this area you can specify tasks that must be be performed before starting the selected run/debug configuration. The tasks are performed in the order they appear in the list.
Click this icon to add one of the following available tasks:
Run External tool: select to run an external application. In the dialog that opens, select one or multiple applications you want to run. If it is not defined in IntelliJ IDEA yet, add its definition. For more information, see Configuring Third-Party Tools and External Tools.
Run Another Configuration: select to execute another run/debug configuration. In the dialog that opens, select the configuration to be run.
If an error occurs during compilation, IntelliJ IDEA won't attempt to start the run/debug configuration.
Build, no error check: the same as the Build option, but IntelliJ IDEA will try to start the run/debug configuration irrespective of the compilation results.
Build Artifacts: select this option to build an artifact or artifacts. In the dialog that opens, select the artifact or artifacts that should be built.
Run Ant target: select this option to run an Ant target. In the dialog that opens, select the target to be run.
Run Grunt task: select this option to run a Grunt task. In the Grunt task dialog box that opens, specify the Gruntfile.js where the required task is defined, select the task to execute, and specify the arguments to pass to the Grunt tool.
Specify the location of the Node.js interpreter, the parameters to pass to it, and the path to the grunt-cli package.
Run Gulp task: select this option to run a Gulp task. In the Gulp task dialog box that opens, specify the Gulpfile.js where the required task is defined, select the task to execute, and specify the arguments to pass to the Gulp tool.
Specify the location of the Node.js interpreter, the parameters to pass to it, and the path to the gulp package.
Run Maven Goal: select this option to run a Maven goal. In the dialog that opens, select the goal to be run.
Start React Native Bundler: select this option to run the bundler automatically, as part of a running or debugging session. by default, this is done through react-native start. If your application uses Expo, you need to run the development server via the start npm task. To do that, click , then in the Configure React Native dialog, choose npm script and select start from the list.
If the Check errors checkbox is selected, the compiler will show all the errors and the run configuration will not start.
If the Check errors checkbox is cleared, the compiler will show all the detected errors but the run configuration still will be launched.
Generate CoffeeScript Source Maps: select this option to generate the source maps for your CoffeeScript sources. In the dialog that opens, specify where your CoffeeScript source files are located.
Upload files to Remote Host: select this option to have the application files automatically uploaded to the server according to the default server access configuration.