OpenUI5 Documentation Update 23.10.2024

docs/Batch_Control_74142a3.md

@@ -47,7 +47,7 @@ The following group IDs are possible:
 
 -   An application group ID is a non-empty string consisting of alphanumeric characters from the basic Latin alphabet, including the underscore. By default, an application group has the submit mode `sap.ui.model.odata.v4.SubmitMode.API`. It is possible to use a different submit mode; for details see section [Define submit mode for an application group ID](Batch_Control_74142a3.md#loio74142a38e3d4467c8d6a70b28764048f__section_e1x_pfg_1cb).
 
--   With [`sap.ui.model.odata.v4.Context#delete`](https://sdk.openui5.org/api/sap.ui.model.odata.v4.Context%23methods/delete), [`sap.ui.model.odata.v4.ODataModel#delete`](https://sdk.openui5.org/api/sap.ui.model.odata.v4.ODataModel%23methods/delete), and [`sap.ui.model.odata.v4.ODataContextBinding#execute`](https://sdk.openui5.org/api/sap.ui.model.odata.v4.ODataContextBinding%23methods/execute), you can also use the `$single` group ID. With this group ID, a single batch request is sent directly, similar to `sap.ui.model.odata.v4.SubmitMode.Direct` groups.
+-   With [`sap.ui.model.odata.v4.Context#delete`](https://sdk.openui5.org/api/sap.ui.model.odata.v4.Context%23methods/delete), [`sap.ui.model.odata.v4.ODataModel#delete`](https://sdk.openui5.org/api/sap.ui.model.odata.v4.ODataModel%23methods/delete), and [`sap.ui.model.odata.v4.ODataContextBinding#invoke`](https://sdk.openui5.org/api/sap.ui.model.odata.v4.ODataContextBinding%23methods/invoke), you can also use the `$single` group ID. With this group ID, a single batch request is sent directly, similar to `sap.ui.model.odata.v4.SubmitMode.Direct` groups.
 
 To specify the group ID for implicit requests, use the parameters `$$groupId` \(group ID for read requests\) and `$$updateGroupId` \(group ID for update requests\) for the binding which initiates the request \(see the [ODataModel.bindList](https://sdk.openui5.org/api/sap.ui.model.odata.v4.ODataModel/methods/bindList), [ODataModel.bindContext](https://sdk.openui5.org/api/sap.ui.model.odata.v4.ODataModel/methods/bindContext) and [ODataModel.bindProperty](https://sdk.openui5.org/api/sap.ui.model.odata.v4.ODataModel/methods/bindProperty) API documentation\).
 

docs/Number_Format_91f2f28.md

@@ -14,7 +14,7 @@ The `sap.ui.core.format.NumberFormat` class can be used to parse a string repres
 
 `NumberFormat` uses the parameters defined for the current locale. These parameters can be overwritten on each instance by setting the format options.
 
-There are four types of formatters defined in `NumberFormat`:
+There are five types of formatters defined in `NumberFormat`:
 
 -   Integer formatter: formats and parses only the integer digits; decimal digits are ignored
 
@@ -24,6 +24,8 @@ There are four types of formatters defined in `NumberFormat`:
 
 -   Currency formatter: formats the number by using the parameters defined for the given currency code. Either currency symbol, currency code, or none of both can be included in the final formatted string. It parses the given string into an array which contains both the currency number and currency code.
 
+-   Unit formatter: formats the number by using the parameters defined for the given unit.
+
 
 ***
 

docs/Step_1_Overview_and_Testing_Strategy_ab134ef.md

@@ -23,7 +23,7 @@ In this step, we will take a look at the prototype and define the test strategy
 
 **The prototype app**
 
-![](images/loio7946d242c8a14ac39fb22556b59d4bcd_HiRes.png "The prototype app")
+![](images/loio7946d242c8a14ac39fb22556b59d4bcd_LowRes.jpg "The prototype app")
 
 ***
 
@@ -51,7 +51,7 @@ With the downloaded code, you now have the bulletin board prototype, set up acco
 
 -   **Entry Page**
 
-    In this tutorial, we will often switch between testing application features manually, and running automated tests. The `webapp/test/test.html` file provides a list of entry points for the app so that you do not have to enter the URLs manually. From this page you can open the app with mock data, run the unit tests, run the integration tests, or run the app’s test suite \(this will be added later in the tutorial\). Note that in a productive scenario we would have an additional entry point that calls the app with a real service. At this stage we are working with mock data and don't have a real service for our prototype yet, so we have left this step out.
+    In this tutorial, we will often switch between testing application features manually, and running automated tests. The `webapp/test.html` file provides a list of entry points for the app so that you do not have to enter the URLs manually. From this page you can open the app with mock data or run the app test suite which contains the unit and integration tests. Note that in a productive scenario we would have an additional entry point that calls the app with a real service. At this stage we are working with mock data and don't have a real service for our prototype yet, so we have left this step out.
 
 -   **Home Page**
 
@@ -77,7 +77,7 @@ With the downloaded code, you now have the bulletin board prototype, set up acco
         A comment has an `Author`, a `Date`, and a `CommentText` property. The entity can be identified by the `CommentID` property and is linked to a `post` by the `ParentID`. The corresponding `EntitySet` is `Comments`.
 
 
-    The actual test data containing several mock posts is located in the `webapp/test/service/posts.json` file.
+    The actual test data containing several mock posts is located in the `webapp/localService/mockdata/Posts.json` file.
 
 -   **Testing Functionality**
 
@@ -91,11 +91,15 @@ With the downloaded code, you now have the bulletin board prototype, set up acco
 
     -   **Unit Tests**
 
-        All unit tests are located in the `webapp/test/unit` folder and can be started by calling the `unitTests.qunit.html` file in the same folder. Initially, there are only a few tests for model instantiation and formatters that cover basic functionality in the prototype. We will give you more details about the unit test setup later in the tutorial.
+        All unit tests are located in the `webapp/test/unit` folder. Initially, there are only a few tests for model instantiation and formatters that cover basic functionality in the prototype. We will give you more details about the unit test setup later in the tutorial.
 
     -   **Integration Tests**
 
-        Integration tests are written in OPA5 – a tool for integration testing that is included in OpenUI5 – and can be found in the `webapp/test/integration` folder. You can start all OPA5 tests by calling the `opaTests.qunit.html` file in the same folder. OPA5 tests are organized in test journeys, and we have included a worklist journey that checks if the table of posts is displayed properly. We will give you more details about the integration test setup later in the tutorial.
+        Integration tests are written in OPA5 – a tool for integration testing that is included in OpenUI5 – and can be found in the `webapp/test/integration` folder. OPA5 tests are organized in test journeys, and we have included a worklist journey that checks if the table of posts is displayed properly. We will give you more details about the integration test setup later in the tutorial.
+
+    -   **Test Suite**
+
+        Unit and integration tests are part of a test suite that is located at `webapp/test/testsuite.qunit.js`. The test suite lists all tests of a project and contains configuration for the test setup. The test suite can be started by opening the `testsuite.qunit.html` file in the same folder.
 
 
 -   **Other quality-related features of the app**
@@ -116,7 +120,9 @@ With the downloaded code, you now have the bulletin board prototype, set up acco
 
 
 
-Now that we have a running prototype, we can further extend it with additional tests and features. Make sure that the app is running by calling the test page, the unit tests, and the integration tests from the entry page `webapp/test/test.html`. The app should display a list of bulletin board posts as seen in the screenshot above and the tests should run without errors.
+Now that we have a running prototype, we can further extend it with additional tests and features. Make sure that the app is running by calling the test page and the test suite from the entry page `webapp/test.html`. The app should display a list of bulletin board posts as seen in the screenshot above and the tests should run without errors.
+
+![](images/loiob5ea0590dd68474786ab3b494564fae3_LowRes.jpg)
 
 ***
 

docs/Step_2_A_First_Unit_Test_b81736e.md

@@ -47,7 +47,7 @@ As we use Test Driven Development \(TDD\) we define the test case first, before
 
 ### Unit Test Setup
 
-All unit tests are located in the `webapp/test/unit` folder and can be started manually by calling the `unitTests.qunit.html` file in the same folder or the entry page. This HTML page is a QUnit runner that calls all unit tests of the app and displays the test results in a readable format.
+All unit tests are located in the `webapp/test/unit` folder and can be started by opening the `webapp/test/testsuite.qunit.html` in your browser and selecting `unit/unitTests`.
 
 > ### Note:  
 > Some testrunners like Karma do not require an HTML page to invoke the tests but work with configuration files instead. They can directly invoke the `AllTests.js` file and log the test results in their own format. Therefore we make sure that the `AllTests.js` file does not contain any UI output and just calls the various test cases of the app.
@@ -80,15 +80,14 @@ You can view and download all files in the *Samples* in the Demo Kit at [Testing
 ### webapp/model/formatter.js
 
 ```js
-sap.ui.define([
-	"sap/m/Text"
-], function (Text) {
-	"use strict";
-	return {
-		numberUnit: function (sValue) {
-			…
-		},
-		priceState: function () {
+
+sap.ui.define([], function () {
+		"use strict";
+	     return {
+		       numberUnit: function (sValue) {
+		  	// …
+		       },
+		       priceState: function () {
 		}
 
 	};
@@ -102,13 +101,14 @@ First we think about the feature that we want to implement. We want to introduce
 ### webapp/test/unit/model/formatter.js
 
 ```js
+/*global QUnit*/
 sap.ui.define([
-	"./model/formatter"
+	  "sap/ui/demo/bulletinboard/model/formatter"
 ], function (formatter) {
 	"use strict";
 
 	QUnit.module("Number unit");
-		…
+		// …
 	QUnit.module("Price State");
 
 	function priceStateTestCase(oOptions) {
@@ -188,14 +188,11 @@ We add a new QUnit module for our price state tests after the number unit conver
 
 The assert object – a special object injected by QUnit – is passed on as a reference to the function. QUnit is loaded once for the whole unit testing part of the app.
 
-> ### Note:  
-> The main page for calling the unit tests is `webapp/test/unit/unitTests.qunit.html`. In this file we load the QUnit runtime and an `AllTests.js` file that loads and directly executes all files with unit tests. The other content of this file is just HTML for displaying the QUnit test result page.
-
 And now for the actual test cases: Whenever we want to start a new test we call `QUnit.test` with a test description and a callback function containing the test logic as an argument. The callback is invoked with a special assert object that is maintained by QUnit. We can simply call assertions as we saw above.
 
 Inside each test we simply call our reuse function with different parameters for the price and the expected state that reflect our specification above. With five tests we can check the most important cases for our price state converter. There are four tests for the four different states and one edge case test with the value `50`, that makes sure that the correct state is chosen.
 
-That’s it, you just wrote your first unit test. When you call the `webapp/test/unit/unitTests.qunit.html` file in your browser, you can see that the first module for the number unit formatter is still green but our price state tests are red and failing. The error message tells us that the result of the empty formatter function is not as expected.
+That’s it, you just wrote your first unit test. When you run the test in your browser, you can see that the first module for the number unit formatter is still green but our price state tests are red and failing. The error message tells us that the result of the empty formatter function is not as expected.
 
 TDD methodology tells us to do the implementation as soon as the test fails and to come back to testing as soon as the tests are successful again. You run the unit tests after each code change, and you're done when the test does not fail anymore. We now switch to the implementation part and define the details of the formatter function in the next step.
 

docs/Step_3_Adding_the_Price_Formatter_2bf4892.md

@@ -35,29 +35,28 @@ You can view and download all files in the *Samples* in the Demo Kit at [Testing
 ### webapp/model/formatter.js
 
 ```js
-sap.ui.define([
-	"sap/m/Text"
-], function (Text) {
-	"use strict";
-	return {
-		numberUnit: function (sValue) {
-			…
-		},
-		/**
-		 * Defines a value state based on the price
-		 *
-		 * @public
-		 * @param {number} iPrice the price of a post
-		 * @returns {string} sValue the state for the price
-		 */
-		priceState: function (iPrice) {
-			if (iPrice < 50) {
+
+sap.ui.define([], function () {
+	   "use strict";
+	   return {
+		     numberUnit: function (sValue) {
+			// …
+		     },
+		     /**
+		     * Defines a value state based on the price
+		     *
+		     * @public
+		     * @param {number} iPrice the price of a post
+		     * @returns {string} sValue the state for the price
+		     */
+		     priceState: function (iPrice) {
+			     if (iPrice < 50) {
 				return "Success";
-			} else if (iPrice >= 50 && iPrice < 250) {
+			     } else if (iPrice >= 50 && iPrice < 250) {
 				return "None";
-			} else if (iPrice >= 250 && iPrice < 2000) {
+			     } else if (iPrice >= 250 && iPrice < 2000) {
 				return "Warning";
-			} else {
+			     } else {
 				return "Error";
 			}
 		}
@@ -69,7 +68,7 @@ We change the empty formatter function that we have added in the last step and a
 
 The input for the formatter is the price value from the model and the result is the state as a `string` value. The actual implementation logic is quite simple and returns a semantic state value based on the price as we have seen already in the test. There are four cases that are reflected in the `if/else` statements inside the formatter.
 
-You can now run the file `webapp/test/unit/unitTests.qunit.html` and check if the unit tests run successfully. You should see your new test cases on the result page. If the overall result is successful then we have successfully implemented our first feature.
+You can now run the file `webapp/test/testsuite.qunit.html` in your browser and select `unit/unitTests` to check if the unit tests run successfully. You should see your new test cases on the result page. If the overall result is successful then we have successfully implemented our first feature.
 
 ***