ci-5366: remove testing add-on references (#246)

* ci-5366: remove testing add-on references

* ci-5366: update README.md

Author: zoltanszabo-bitrise

README.md

@@ -3,15 +3,15 @@
 [![Step changelog](https://shields.io/github/v/release/bitrise-steplib/steps-deploy-to-bitrise-io?include_prereleases&label=changelog&color=blueviolet)](https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/releases)
 
 Deploys build artifacts to make them available for the user on the build's **Artifacts** tab.
-Sends test results to the Test Reports add-on (build's **Tests** tab).
+Sends test results to the Test Reports (build's **Tests** tab).
 Uploads Pipeline intermediate files to make them available in subsequent Workflows and also uploads Bitrise and user generated html reports.
 
 <details>
 <summary>Description</summary>
 
 The Step accesses artifacts from a directory specified as the `$BITRISE_DEPLOY_DIR` where artifacts generated by previous Steps gets stored.
 These artifacts are then uploaded on the **Artifacts** tab of any given build. For installable artifacts, such as IPAs or APKs, the Step can create a public install page that allows testers to install the app on their devices.
-You can also use the Step to notify users about the build. If you wish to use the Test Reports add-on, you must add this Step in your Workflow since the Step converts test results to the right format and sends them to the add-on.
+You can also use the Step to notify users about the build. If you wish to use the Test Reports, you must add this Step in your Workflow since the Step converts test results to the right format and sends them.
 The Step can also share Pipeline intermediate files. These files are generated by Workflows in a Pipeline intended to be shared with subsequent Workflows.
 Also it collects and uploads all of the html reports located in the `BITRISE_HTML_REPORT_DIR` folder.
 
@@ -77,7 +77,7 @@ Bundletool generates an APK from an Android App Bundle so that you can test the
 
 ## 🧩 Get started
 
-Add this step directly to your workflow in the [Bitrise Workflow Editor](https://devcenter.bitrise.io/steps-and-workflows/steps-and-workflows-index/).
+Add this step directly to your workflow in the [Bitrise Workflow Editor](https://docs.bitrise.io/en/bitrise-ci/workflows-and-pipelines/steps/adding-steps-to-a-workflow.html).
 
 You can also run this step directly with [Bitrise CLI](https://github.com/bitrise-io/bitrise).
 
@@ -163,9 +163,8 @@ This metadata will be saved with the individual files and restored by the [Pull
 
 We welcome [pull requests](https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/pulls) and [issues](https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/issues) against this repository.
 
-For pull requests, work on your changes in a forked repository and use the Bitrise CLI to [run step tests locally](https://devcenter.bitrise.io/bitrise-cli/run-your-first-build/).
+For pull requests, work on your changes in a forked repository and use the Bitrise CLI to [run step tests locally](https://docs.bitrise.io/en/bitrise-ci/bitrise-cli/running-your-first-local-build-with-the-cli.html).
 
 Learn more about developing steps:
 
-- [Create your own step](https://devcenter.bitrise.io/contributors/create-your-own-step/)
-- [Testing your Step](https://devcenter.bitrise.io/contributors/testing-and-versioning-your-steps/)
+- [Create your own step](https://docs.bitrise.io/en/bitrise-ci/workflows-and-pipelines/developing-your-own-bitrise-step/developing-a-new-step.html)

step.yml

@@ -1,12 +1,12 @@
 title: Deploy to Bitrise.io - Build Artifacts, Test Reports, and Pipeline intermediate files
 summary: |-
   Deploys build artifacts to make them available for the user on the build's **Artifacts** tab.
-  Sends test results to the Test Reports add-on (build's **Tests** tab).
+  Sends test results to the Test Reports (build's **Tests** tab).
   Uploads Pipeline intermediate files to make them available in subsequent Workflows and also uploads Bitrise and user generated html reports.
 description: |-
   The Step accesses artifacts from a directory specified as the `$BITRISE_DEPLOY_DIR` where artifacts generated by previous Steps gets stored.
   These artifacts are then uploaded on the **Artifacts** tab of any given build. For installable artifacts, such as IPAs or APKs, the Step can create a public install page that allows testers to install the app on their devices.
-  You can also use the Step to notify users about the build. If you wish to use the Test Reports add-on, you must add this Step in your Workflow since the Step converts test results to the right format and sends them to the add-on.
+  You can also use the Step to notify users about the build. If you wish to use the Test Reports, you must add this Step in your Workflow since the Step converts test results to the right format and sends them.
   The Step can also share Pipeline intermediate files. These files are generated by Workflows in a Pipeline intended to be shared with subsequent Workflows.
   Also it collects and uploads all of the html reports located in the `BITRISE_HTML_REPORT_DIR` folder.
 
@@ -261,7 +261,7 @@ inputs:
       ```
 - addon_api_base_url: https://vdt.bitrise.io/test
   opts:
-    category: Test Reports Addon
+    category: Test Reports
     title: Test API's base URL
     summary: The URL where test API is accessible.
     description: |
@@ -270,7 +270,7 @@ inputs:
     is_dont_change_value: true
 - addon_api_token: $ADDON_VDTESTING_API_TOKEN
   opts:
-    category: Test Reports Addon
+    category: Test Reports
     title: API Token
     summary: The token required to authenticate with the API.
     description: |

test/converters/junitxml/junitxml.go

@@ -60,7 +60,7 @@ func parseTestReport(result resultReader) (TestReport, error) {
 // merges Suites->Cases->Error and Suites->Cases->SystemErr field values into Suites->Cases->Failure field
 // with 2 newlines and error category prefix
 // the two newlines applied only if there is a failure message already
-// this is required because our testing addon currently handles failure field properly
+// this is required because our testing service currently handles failure field properly
 func convertTestReport(report TestReport) testreport.TestReport {
 	convertedReport := testreport.TestReport{
 		XMLName: report.XMLName,