Test using JUnit

JUnit is a simple framework for writing repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.

Based on your testing practices you can choose to create a combination of Test Suites, Test Cases, and Test Steps that will be created in QMetry after importing the automation result file. You need to provide a value in the automationHierarchy parameter in Automation API while importing the test results. Based on the table below the Test artifacts will be created in QMetry.

Automation Hierarchy Values	Following QMetry assets will be created and linked	Test Suite	Test Case	Test Step
1	Testsuite, Test Case, Test Step	Testsuite will be created based on testsuiteName parameter in Automation API or Auto generated if not mentioned.	<testsuite> tag : Parsed from the result file. Junit File Type 1: Wherein testsuite "name" matches the test case "classname". Test Suite will have test cases as per the <testsuite> tag with steps as per the <testcase> tags. Only one version of test cases will be created with multiple test steps. <testsuite> tag: Parsed from the result file. Junit File Type 2: Wherein testsuite "name" does not match the test case "classname". Test Suite will have multiple versions of the same test case linked as per the <testsuite> tag. The number of versions will match the occurrences of the <testcase> tag. For each test case version, there will be one test step.	<testcase> tag under the <testsuite> tag : Parsed from the result file. Classname.name will be the Test Step Description. If the result file does not have a classname tag, the Test Step Description will begin without a dot ( . ) e.g., name. Execution Status in QMetry will be determined based on the result mentioned in the result file as shown below.
				Tag inside <testcase>	Execution Status in QMetry
				<failure>	Failed
				no tags	Passed
				<error>	If the Aborted status is found in the JUnit result file either by referring to the Status or Error Tag	QMetry will set the Test Case Execution Status or Step Execution Status as
					If the Project have the custom execution status “Aborted”	Aborted
					If the Project does not have the custom execution status “Aborted”	Failed
				<skipped>	If the Skipped status is found in the JUnit result file by referring to the Status	QMetry will set the Test Case Execution Status or Step Execution Status as
					If the Project have the custom execution status “Skipped”	Skipped
					If the Project does not have the custom execution status “Skipped”	Not Applicable
2	Testsuite, Test Case	Testsuite will be created based on testsuiteName parameter in Automation API or Auto generated if not mentioned.	<testcase> tag under the <testsuite> tag : Parsed from the result file. classname.name will be the Test Case summary. If the result file does not have a classname tag, the Test Case Summary will begin without a dot ( . ) e.g., name.	NA
				Tag inside <testcase>	Execution Status in QMetry
				<failure>	Failed
				no tags	Passed
				<error>	If the Aborted status is found in the JUnit result file either by referring to the Status or Error Tag	QMetry will set the Test Case Execution Status or Step Execution Status as
					If the Project have the custom execution status “Aborted”	Aborted
					If the Project does not have the custom execution status “Aborted”	Failed
				<skipped>	If the Skipped status is found in the JUnit result file by referring to the Status	QMetry will set the Test Case Execution Status or Step Execution Status as
					If the Project have the custom execution status “Skipped”	Skipped
					If the Project does not have the custom execution status “Skipped”	Not Applicable
3	Testsuite, Test Case	<testsuite> tag	<testcase> tag under the <testsuite> tag : Parsed from the result file. classname.name will be the Test Case summary. If the result file does not have a classname tag, the Test Case Summary will begin without a dot ( . ) e.g., name.	NA
				Tag inside <testcase>	Execution Status in QMetry
				<failure>	Failed
				no tags	Passed
				<error>	If the Aborted status is found in the JUnit result file either by referring to the Status or Error Tag	QMetry will set the Test Case Execution Status or Step Execution Status as
					If the Project have the custom execution status “Aborted”	Aborted
					If the Project does not have the custom execution status “Aborted”	Failed
				<skipped>	If the Skipped status is found in the JUnit result file by referring to the Status	QMetry will set the Test Case Execution Status or Step Execution Status as
					If the Project have the custom execution status “Skipped”	Skipped
					If the Project does not have the custom execution status “Skipped”	Not Applicable

Supported Version: 1.2.5

Supported file types : XML

Sample Test Result File

Automation Hierarchy 1

Junit File Type 1: Click here to download a sample file.

Junit File Type 2: Click here to download a sample file.

Automation Hierarchy 2

Click here to download a sample file.

Automation Hierarchy 3

Click hereto download a sample file.

Note

“Skip” status in the automation result file will be applied as "Not Applicable" instead of "Not Run" for automation test executions upload into QMetry.

Reuse Manual Test Cases

Keyword

Applicable to

Automation Hierarchy

Description

testEntityKey

1,2,3

Download Sample File

When a valid entity key of the test case is passed through the result XML file and the executed test steps match with the steps and summary of any version of the existing test case, then the existing test case version will be reused.
When a valid entity key of the test case is passed through the result XML file and the executed test steps do not match with the steps of any version of the existing test case, then a new version of the test case will be created.
When an invalid/archived test case entity is passed through the result XML file:
- If the executed test steps match with the steps and summary of any version of the existing test case, then the existing test case version will be reused.
- If the executed test steps do not match with the steps and summary of any version of the existing test case, then a new test case will be created using that <testcase>.
When latest version of test case is archived and older versions are not archived:
- If the executed test steps match with the steps and summary of any unarchived version of the existing test case, then the existing unarchived test case version will be reused.
- If the executed test steps do not match with the steps and summary of any unarchived version of the existing test case, then a new test case will be created and linked to the test suite. Execution Status will also be updated.
If a manual test case includes the manual steps, which are same as test-methods (using sharable test case), then on uploading test result using API, a new version will be created.
If the result file contains multiple test suites with same summary, then test cases are linked to respective test suites.
Multiple test case keys (i.e. testEntityKey) can be linked with a single test suite, which will update/create multiple test cases and link these test cases with an automated test suite. Multiple test case keys can be passed in the same tag e.g.

testEntityKey="FIT-TC-1 FIT-TC2 FIT-TC-3"

If multiple requirements are linked to the test cases, then the requirements will be linked individually to the mentioned test case keys.

Link Requirements to Test Case

Keyword

Applicable to

Automation Hierarchy

Description

requirementEntityKey

1,2,3

Download Sample File

Auto-link internal requirements with Junit test cases using the keyword "requirementEntityKey" to specify the entity key in the result file.

The keyword is only used for internal tracker requirements, i.e. QMetry requirements. The mentioned QMetry requirement will be linked to the created/linked test case.

In case of internal tracker, users can also link cross project requirements to the test case.
- Users should have access to the cross project
- The user role should have the "Link" permission for Test Case and Requirement modules.
Multiple requirementEntityKey can be used in the same tag in the file to link multiple internal requirements to the test cases. e.g.

requirementEntityKey="FIT-RQ-20 FTA-RQ-154"

If requirementEntityKey and requirementExternalKey both keys are used in the file, then the preference will be given to the internal tracker key, i.e. requirementEntityKey.
For Automation Hierarchy 1: The requirementEntityKey parameter should be mentioned in the <testsuite> tag.
For Automation Hierarchy 2 & 3: The requirementEntityKey parameter should be mentioned in the <testcase> tag.

requirementExternalKey

1,2,3

Download Sample File

Auto-link requirements synced from external trackers (e.g., Jira, Azure) with Junit test cases uploaded through automation import using the keyword "requirementExternalKey" to specify the external issue/work item key in the result file.

The key word is used for external tracker requirements, i.e. Jira/Azure. The mentioned external requirement will be linked to the created/linked test case.

Note: The requirements from external tracker should have already been imported into QMetry Requirements module.

In case of external tracker, users can only link current project requirements to the test case.
Multiple requirementExternalKey can be used in the same tag in the file to link multiple external requirements to the test cases. e.g.

requirementExternalKey ="HT-30 HT-54"

If requirementEntityKey and requirementExternalKey both keys are used in the file, then the preference will be given to the internal tracker key, i.e. requirementEntityKey.
For Automation Hierarchy 1: The requirementExternalKey parameter should be mentioned in the <testsuite> tag.
For Automation Hierarchy 2 & 3: The requirementExternalKey parameter should be mentioned in the <testcase> tag.

In this section:

Test using JUnit

Sample Test Result File

Note

Reuse Manual Test Cases

Link Requirements to Test Case

Search results