GUI Connection Management/en - Versionsgeschichte

Matilk am 17. Januar 2023 um 16:52 Uhr

2023-01-17T16:52:07Z

← Nächstältere Version		Version vom 17. Januar 2023, 16:52 Uhr
Zeile 1:		Zeile 1:
	= Introduction =		= Introduction =
	Blocks of a library for a GUI technology usually work without a connection ~~being specified directly~~. Instead, they use the connection ~~that is available~~. However, when running a ~~testplan~~, ~~several~~ connections can be used. This page explains how to specify which connection to use when.		Blocks of a library for a GUI technology usually work without directly specifying a connection. Instead, they use the available connection. However, when running a test plan, multiple connections can be used. This page explains how to specify which connection to use when.

	Expecco uses a two-level system to determine which connection to use. On the one hand there is the variable environment of the executed block. ~~Which~~ connection to ~~use~~ can be set by an entry there. Usually this is done automatically on connect and can be modified by appropriate blocks. This option typically ~~takes~~ ~~effect within~~ test runs where the connection setup is integrated. If there is no information in the variable environment, the last selected connection will be used. This can be controlled by the GUI browser and is used for example each time a single block is executed.		Expecco uses a two-level system to determine which connection to use. On the one hand there is the variable environment of the executed block. The connection to be used can be set by an entry there. Usually this is done automatically on connect and can be modified by appropriate blocks. This option is typically used in test runs where the connection setup is integrated. If there is no information in the variable environment, the last selected connection will be used. This can be controlled by the GUI browser and is used, for example, each time a single block is executed.

	= Variable Environment =		= Variable Environment =
	Especially when ~~several~~ connections ~~are used~~ in parallel, the variable environment can be used to specify which connection should be used. Each technology has its own fixed name by which a so-called test runner is stored in the environment and another name by which the current connection is stored. The test runner has a mapping between connection names and the ~~respective~~ actual connection. For each used technology, an appropriate test runner will be created if required and will stored in the variable environment, so it can be found there for later use. When a connection is started using an appropriate connect block, this test runner will remember the connection by its name. To set the active connection there are blocks in the libraries, called ''Set Current Connection'' or ''Set Connection Scope'' or similar. They write the connection name in the variable environment. A normal action block will now retrieve the name of the active connection and the test runner it belongs to from the environment and knows like this which connection to use. If there is no information about this in the environment, it will use instead the connection that was last selected in the GUI browser. Disconnecting by name also is done by the name mapping of the test runner.		Especially when using multiple connections in parallel, the variable environment can be used to specify which connection should be used. Each technology has its own fixed name under which a so-called test runner is stored in the environment, and another name under which the current connection is stored. The test runner has a mapping between the connection names and the actual connection.

			A test runner is created for each technology used and stored in the variable environment where it can be found for later use. When a connection is started using an appropriate connect block, this test-runner will remember the connection by its name.

			To set the active connection, there are blocks in the libraries called ''Set Current Connection'' or ''Set Connection Scope'' or similar. These write the connection name to the environment. A normal action block will now retrieve the name of the active connection and the test-runner to which it belongs from the environment and thus know which connection to use. If there is no information in the environment, it will use the connection that was last selected in the GUI browser instead. Disconnecting by name is also done by the name mapping of the test-runner.

	The names of the environment variables for each technology are:		The names of the environment variables for each technology are:
Zeile 21:		Zeile 25:
	\|}		\|}

	These variables are ~~created~~ automatically in the ~~executor~~ environment, so they are present ~~for~~ the ~~whole~~ execution, but ~~are~~ ~~gone~~ ~~as well, after~~ the execution finished. Alternatively you can define one of ~~those~~ variables in the environment of a ~~testplan~~ or block. In this case the variable there ~~will~~ be ~~used~~. This makes it easier to use two connections in parallel in one execution.		These variables are automatically created in the execution environment, so they are present throughout the execution, but also disappear when the execution is finished. Alternatively, you can define one of these variables in the environment of a test plan or block. In this case, a separate version of the variable is used there and in the subordinate blocks. This makes it easier to use two connections in parallel in one execution.

	;'''Example 1:''' Execute the same sequence on two connections in parallel		;'''Example 1:''' Execute the same sequence on two connections in parallel
	:~~In each of two blocks set~~ the environment variable for the active connection. Then set a different active connection for each ~~of them~~ and ~~after that~~ add the same block ~~containing~~ the ~~desired~~ sequence. Both blocks can now be executed in parallel and each will take its own connection.		:Set the environment variable for the active connection in each of the two blocks. Then set a different active connection for each and add the same block with the sequence you want. Both blocks can now be executed in parallel and each will take its own connection.
	:[[Datei:ParallelGUIConnections1.png\|mini\|800px\|left\|Example 1: TestSequence is the same block in both runs, but will use a different connection (name).]]		:[[Datei:ParallelGUIConnections1.png\|mini\|800px\|left\|Example 1: TestSequence is the same block in both runs, but will use a different connection (name).]]
	<br clear=all>		<br clear=all>
	;'''Example 2:''' Execute the same test multiple times in parallel		;'''Example 2:''' Execute the same test multiple times in parallel
	:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can ~~as well~~ use ~~several~~ test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.		:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can also use multiple test runners. In this case, define the environment variable for the test runner for your test. When the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.
	:[[Datei:ParallelGUIConnections2.png\|mini\|578px\|left\|Example 2:TestSequence is the same block in both runs, but will use a different Test Runner with the same name for different connections.]]		:[[Datei:ParallelGUIConnections2.png\|mini\|578px\|left\|Example 2:TestSequence is the same block in both runs, but will use a different Test Runner with the same name for different connections.]]
	<br clear=all>		<br clear=all>

	= GUI Browser =		= GUI Browser =
	~~When~~ ~~creating~~ or ~~editing~~ ~~testsuites,~~ ~~the~~ ~~GUI~~ ~~browser~~ is ~~very~~ ~~helpful~~. You can use it to create new connections, all active connections ~~are displayed there~~ and ~~you can~~ create or edit test sequences, for example by using ~~the respective recorder of~~ the appropriate technology.		The GUI browser is very useful when creating or editing test suites. You can use it to create new connections, view all active connections, and create or edit test sequences, for example using the appropriate technology recorder.

	~~In the~~ GUI browser you ~~can~~ execute ~~single~~ blocks. For ~~them~~ the connection ~~that is~~ selected on the left side ~~will be~~ used. ~~Generally~~, when ~~selecting~~ a connected connection in the GUI browser, it is set as current connection and will be used, if there is no ~~different~~ information in the environment of an executed block.		The GUI browser allows you to execute individual blocks. For these, the connection selected on the left-hand side is used. In general, when you select a connected connection in the GUI browser, it is set as the current connection and will be used if there is no information to the contrary in the environment of an executed block.

	= Common UI Blocks=		= Common UI Blocks=
	There are blocks that can theoretically be used with each technology, ~~though~~ some ~~functionalities~~ ~~might~~ not be supported. You find them in the Common GUI Library. They use their own ~~Test~~ ~~Runner,~~ which ~~know~~ ~~all~~ connections. It uses the following environment variables:		There are blocks that can theoretically be used with each technology, although some functionality may not be supported. You can find them in the Common GUI Library. They use their own test runner which knows the connections of all the technologies used. It uses the following environment variables:
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
Zeile 48:		Zeile 52:

	== Caution With Parallel Connections ==		== Caution With Parallel Connections ==
	If your test uses only one connection, ~~there~~ is no difference whether you use a Common UI block or a technology block. ~~With~~ multiple connections ~~however~~ you ~~must~~ be careful! Because ~~it is not known at~~ the Common UI blocks which technology is to ~~be used~~, you must also ensure that the correct connection is set ~~when~~ using two different technologies in parallel. If you ~~use~~ technology blocks, ~~you~~ ~~have~~ no ~~problems~~ ~~here,~~ because different ~~Test~~ ~~Runners~~ and environment variables are used for the different technologies.		If your test uses only one connection, it makes no difference whether you use a Common UI block or a technology block. However, with multiple connections you need to be careful! Because the Common UI blocks do not know which technology to use, you must also ensure that the correct connection is set if you are using two different technologies in parallel. If you are using technology blocks, this is not a problem because different test runners and environment variables are used for the different technologies.

Matilk: /* Variable Environment */

2023-01-10T08:19:40Z

Variable Environment

← Nächstältere Version		Version vom 10. Januar 2023, 08:19 Uhr
Zeile 30:		Zeile 30:
	:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can as well use several test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.		:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can as well use several test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.
	:[[Datei:ParallelGUIConnections2.png\|mini\|578px\|left\|Example 2:TestSequence is the same block in both runs, but will use a different Test Runner with the same name for different connections.]]		:[[Datei:ParallelGUIConnections2.png\|mini\|578px\|left\|Example 2:TestSequence is the same block in both runs, but will use a different Test Runner with the same name for different connections.]]
			<br clear=all>

	= GUI Browser =		= GUI Browser =

Matilk: /* Variable Environment */ captions for the images

2023-01-10T08:19:07Z

Variable Environment: captions for the images

← Nächstältere Version		Version vom 10. Januar 2023, 08:19 Uhr
Zeile 25:		Zeile 25:
	;'''Example 1:''' Execute the same sequence on two connections in parallel		;'''Example 1:''' Execute the same sequence on two connections in parallel
	:In each of two blocks set the environment variable for the active connection. Then set a different active connection for each of them and after that add the same block containing the desired sequence. Both blocks can now be executed in parallel and each will take its own connection.		:In each of two blocks set the environment variable for the active connection. Then set a different active connection for each of them and after that add the same block containing the desired sequence. Both blocks can now be executed in parallel and each will take its own connection.
	:[[Datei:ParallelGUIConnections1.png\|800px\|Example 1]]		:[[Datei:ParallelGUIConnections1.png\|mini\|800px\|left\|Example 1: TestSequence is the same block in both runs, but will use a different connection (name).]]
			<br clear=all>

	;'''Example 2:''' Execute the same test multiple times in parallel		;'''Example 2:''' Execute the same test multiple times in parallel
	:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can as well use several test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.		:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can as well use several test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.
	:[[Datei:ParallelGUIConnections2.png\|578px\|Example 2]]		:[[Datei:ParallelGUIConnections2.png\|mini\|578px\|left\|Example 2:TestSequence is the same block in both runs, but will use a different Test Runner with the same name for different connections.]]

	= GUI Browser =		= GUI Browser =

Matilk: /* Variable Environment */ Images

2023-01-09T13:43:58Z

Variable Environment: Images

← Nächstältere Version		Version vom 9. Januar 2023, 13:43 Uhr
Zeile 25:		Zeile 25:
	;'''Example 1:''' Execute the same sequence on two connections in parallel		;'''Example 1:''' Execute the same sequence on two connections in parallel
	:In each of two blocks set the environment variable for the active connection. Then set a different active connection for each of them and after that add the same block containing the desired sequence. Both blocks can now be executed in parallel and each will take its own connection.		:In each of two blocks set the environment variable for the active connection. Then set a different active connection for each of them and after that add the same block containing the desired sequence. Both blocks can now be executed in parallel and each will take its own connection.
			:[[Datei:ParallelGUIConnections1.png\|800px\|Example 1]]

	;'''Example 2:''' Execute the same test multiple times in parallel		;'''Example 2:''' Execute the same test multiple times in parallel
	:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can as well use several test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.		:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can as well use several test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.
			:[[Datei:ParallelGUIConnections2.png\|578px\|Example 2]]

	= GUI Browser =		= GUI Browser =

Matilk: /* Common UI Blocks */

2022-12-22T17:41:32Z

Common UI Blocks

← Nächstältere Version		Version vom 22. Dezember 2022, 17:41 Uhr
Zeile 33:		Zeile 33:

	In the GUI browser you can execute single blocks. For them the connection that is selected on the left side will be used. Generally, when selecting a connected connection in the GUI browser, it is set as current connection and will be used, if there is no different information in the environment of an executed block.		In the GUI browser you can execute single blocks. For them the connection that is selected on the left side will be used. Generally, when selecting a connected connection in the GUI browser, it is set as current connection and will be used, if there is no different information in the environment of an executed block.

			= Common UI Blocks=
			There are blocks that can theoretically be used with each technology, though some functionalities might not be supported. You find them in the Common GUI Library. They use their own Test Runner, which know all connections. It uses the following environment variables:
			{\| class="wikitable"
			\|-
			! !! Variable for the Test Runner !! Variable for the Active Connection
			\|-
			\| Master TestRunner\|\| MASTER_TEST_RUNNER \|\| CURRENT_MASTER_CONNECTION
			\|}
			Since expecco 22.2, the current connection of the Master Test Runner will be always set whenever a technology block changes the current connection. The same applies for selecting a connection in the GUI Browser.

			== Caution With Parallel Connections ==
			If your test uses only one connection, there is no difference whether you use a Common UI block or a technology block. With multiple connections however you must be careful! Because it is not known at the Common UI blocks which technology is to be used, you must also ensure that the correct connection is set when using two different technologies in parallel. If you use technology blocks, you have no problems here, because different Test Runners and environment variables are used for the different technologies.

Matilk: Weiterleitung auf GUI Connection Management entfernt

2022-12-16T14:04:12Z

Weiterleitung auf GUI Connection Management entfernt

← Nächstältere Version		Version vom 16. Dezember 2022, 14:04 Uhr
Zeile 1:		Zeile 1:
			= Introduction =
	#WEITERLEITUNG [[GUI_Connection_Management]]
			Blocks of a library for a GUI technology usually work without a connection being specified directly. Instead, they use the connection that is available. However, when running a testplan, several connections can be used. This page explains how to specify which connection to use when.

			Expecco uses a two-level system to determine which connection to use. On the one hand there is the variable environment of the executed block. Which connection to use can be set by an entry there. Usually this is done automatically on connect and can be modified by appropriate blocks. This option typically takes effect within test runs where the connection setup is integrated. If there is no information in the variable environment, the last selected connection will be used. This can be controlled by the GUI browser and is used for example each time a single block is executed.

			= Variable Environment =
			Especially when several connections are used in parallel, the variable environment can be used to specify which connection should be used. Each technology has its own fixed name by which a so-called test runner is stored in the environment and another name by which the current connection is stored. The test runner has a mapping between connection names and the respective actual connection. For each used technology, an appropriate test runner will be created if required and will stored in the variable environment, so it can be found there for later use. When a connection is started using an appropriate connect block, this test runner will remember the connection by its name. To set the active connection there are blocks in the libraries, called ''Set Current Connection'' or ''Set Connection Scope'' or similar. They write the connection name in the variable environment. A normal action block will now retrieve the name of the active connection and the test runner it belongs to from the environment and knows like this which connection to use. If there is no information about this in the environment, it will use instead the connection that was last selected in the GUI browser. Disconnecting by name also is done by the name mapping of the test runner.

			The names of the environment variables for each technology are:
			{\| class="wikitable"
			\|-
			! Technology !! Variable for the Test Runner !! Variable for the Active Connection
			\|-
			\| Mobile Testing \|\| MOBILE_TESTING_TEST_RUNNER \|\| CURRENT_MOBILE_TESTING_CONNECTION
			\|-
			\| Java\|\| SWING_TEST_RUNNER \|\| CURRENT_SWING_CONNECTION
			\|-
			\| Selenium WebDriver \|\| SELENIUM_TEST_RUNNER \|\| CURRENT_SELENIUM_CONNECTION
			\|-
			\| WindowsAutomation2\|\| WINDOWS_AUTOMATION_CONNECTION_MANAGER \|\| CURRENT_WINDOWS_AUTOMATION_CONNECTION
			\|}

			These variables are created automatically in the executor environment, so they are present for the whole execution, but are gone as well, after the execution finished. Alternatively you can define one of those variables in the environment of a testplan or block. In this case the variable there will be used. This makes it easier to use two connections in parallel in one execution.

			;'''Example 1:''' Execute the same sequence on two connections in parallel
			:In each of two blocks set the environment variable for the active connection. Then set a different active connection for each of them and after that add the same block containing the desired sequence. Both blocks can now be executed in parallel and each will take its own connection.

			;'''Example 2:''' Execute the same test multiple times in parallel
			:If starting and naming the connection is already part of the test sequence you want to run in parallel, you can as well use several test runners. In this case, define the environment variable for the test runner for your test. If the test is now run in parallel, each will create its own test runner instance and there will be no conflict if the connection names are the same.

			= GUI Browser =
			When creating or editing testsuites, the GUI browser is very helpful. You can use it to create new connections, all active connections are displayed there and you can create or edit test sequences, for example by using the respective recorder of the appropriate technology.

			In the GUI browser you can execute single blocks. For them the connection that is selected on the left side will be used. Generally, when selecting a connected connection in the GUI browser, it is set as current connection and will be used, if there is no different information in the environment of an executed block.

Matilk: Weiterleitung nach GUI Connection Management erstellt

2022-12-16T11:33:08Z

Weiterleitung nach GUI Connection Management erstellt

Neue Seite

#WEITERLEITUNG [[GUI_Connection_Management]]