Merge branch 'main' into 00248-tck-implement-tests-for-tokenfeeschedu…

…leupdatetransaction

eslint.config.js → .eslintrc.cjs

@@ -7,6 +7,7 @@ export default defineConfig([
         console: "readonly",
       },
     },
+    extends: ["plugin:prettier/recommended"],
     rules: {
       "no-console": ["warn", { allow: ["warn"] }],
       "prefer-const": "error",
@@ -15,6 +16,7 @@ export default defineConfig([
       eqeqeq: ["error", "always"],
       "no-multi-spaces": ["error"],
       "no-duplicate-imports": ["error"],
+      "prettier/prettier": "error",
     },
     ignores: ["mochawesome-report/**"],
   },

.prettierrc

@@ -0,0 +1,12 @@
+{
+  "printWidth": 80,
+  "tabWidth": 2,
+  "useTabs": false,
+  "semi": true,
+  "singleQuote": false,
+  "trailingComma": "all",
+  "bracketSpacing": true,
+  "arrowParens": "always",
+  "endOfLine": "lf"
+}
+

README.md

@@ -45,7 +45,7 @@ npm install
 Run specific test file
 
 ```
-npm run test test/account/test_accountCreateTransaction.js
+npm run test src/tests/account-service/test-account-create-transaction.js
 ```
 
 Run all tests

DevelopmentProcess.md → docs/test-specifications/DevelopmentProcess.md

@@ -8,8 +8,8 @@ Since the process outlined will require coordination across all SDKs, having a d
 
 | SDK                   | Lead              | Github handle      |
 |-----------------------|-------------------|--------------------|
-| Javascript/Typescript | Svetoslav Nikolov | @svetoslav-nikol0v |
-| Java                  | Nikita Lebedev    | @thenswan          |
+| Javascript/Typescript | Ivaylo Nikolov | @ivaylonikolov7 |
+| Java                  | Nikola Naydenov    | @naydenovn          |
 | Go                    | Ivan Ivanov       | @0xivanov          |
 | C++                   | Rob Walworth      | @rwalworth         |
 | Swift                 | Ricky Saechao     | @RickyLB           |
@@ -21,9 +21,9 @@ The TCK development process encompasses all work done for a Hedera request type,
 
 ### Step 1: Documentation
 
-Before any development takes place, the tests to be written need to be thought out and put in a markdown file in the `test-specifications` folder. A new file should use the `test-specifications/testSpecificationsTemplate.md` file as a template. The new markdown file should also be placed within a folder within the `test-specifications` folder that contains all the tests for the particular Hedera service that services the request for which tests are being written. For example, if tests are being written for `AccountCreateTransaction`, the `accountCreateTransaction.md` file should be placed in `test-specifications/crypto-service`.
+Before any development takes place, the tests to be written need to be thought out and put in a markdown file in the `test-specifications` folder inside the `docs` directory. A new file should use the `test-specifications/TestSpecificationsTemplate.md` file as a template. The new markdown file should also be placed within a folder within the `test-specifications` folder that contains all the tests for the particular Hedera service that services the request for which tests are being written. For example, if tests are being written for `AccountCreateTransaction`, the `AccountCreateTransaction.md` file should be placed in `test-specifications/crypto-service`.
 
-The items that should be included in a request's test documentation can be seen by looking at the `testSpecificationsTemplate.md` file. These items include:
+The items that should be included in a request's test documentation can be seen by looking at the `TestSpecificationsTemplate.md` file. These items include:
  - Description: A description of the test specification. This, for the most part, should be copy-paste between test files with slight changes for names, links, etc.
  - Design: A brief rundown of what is being tested, how it's being tested, and how the test results can be verified.
  - Request properties: A link to the Hedera documentation for the request.
@@ -49,36 +49,36 @@ Once the tests have been written, they can be put up for in a pull request. The
 
 ### Step 2a: TCK Test Driver
 
-Once the tests are written, approved, and merged, they can then be developed. The approved and merged test documentation should be used to discern what tests to write and how they should operate. Much like the test documentation, the file that contains the code for the tests should be placed within a folder within the `test` folder that contains all the tests for the particular Hedera service that services the request for which the tests are being written. For example, if tests are being written for `AccountCreateTransaction`, the `test_accountCreateTransaction.js` file should be placed in `test/crypto-service`.
+Once the tests are written, approved, and merged, they can then be developed. The approved and merged test documentation should be used to discern what tests to write and how they should operate. Much like the test documentation, the file that contains the code for the tests should be placed within a folder within the `tests` folder that contains all the tests for the particular Hiero service that services the request for which the tests are being written. For example, if tests are being written for `AccountCreateTransaction`, the `test-account-create-transaction.ts` file should be placed in `tests/crypto-service`.
 
 A few guidelines for developing the tests:
- - The name of the test file should match the name of the documentation, with a `test_` prepended to the file name, and obviously the different file extension. So a documentation markdown file named `accountCreateTransaction.md` would have its test implementation file named `test_accountCreateTransaction.js`.
+ - The name of the test file should be `kebap-case` and match the name of the documentation, with a `test-` prepended to the file name, and obviously the different file extension. So a documentation markdown file named `AccountCreateTransaction.md` would have its test implementation file named `test-account-create-transaction.ts`.
  - A `describe` call should be used to wrap all the tests for a request type, and it should be described with the name of the request being tested.
 ```jsx
-describe("AccountCreateTransaction", function () {
+describe("AccountCreateTransaction", () => {
     //...
 });
 ```
  - Another `describe` call should wrap all tests associated with one property/function for the request type and be named the property/function name.
 ```jsx
-describe("AccountCreateTransaction", function () {
+describe("AccountCreateTransaction", () => {
     //...
-    describe("Key", function () {
+    describe("Key", () => {
         //...
     });
     //...
 });
 ```
  - Finally, an `it` call should wrap each test and should use the same name as described in the test documentation, as well as prepended with the test number in parentheses.
 ```jsx
-describe("AccountCreateTransaction", function () {
+describe("AccountCreateTransaction", () => {
     //...
-    describe("Key", function () {
+    describe("Key", () => {
         //...
-        it("(#1) Creates an account with a valid key", async function () {
+        it("(#1) Creates an account with a valid key", async () => {
             //...
         });
-        it("(#2) Creates an account with no key", async function () {
+        it("(#2) Creates an account with no key", async () => {
             //...
         });
         //...

docs/test-specifications/token-service/TokenAssociateTransaction.md

@@ -0,0 +1,145 @@
+# TokenAssociateTransaction - Test specification
+
+## Description:
+This test specification for TokenAssociateTransaction is to be one of many for testing the functionality of the Hedera SDKs. The SDK under test will use the language specific JSON-RPC server return responses back to the test driver.
+
+## Design:
+Each test within the test specification is linked to one of the properties within TokenAssociateTransaction. Each property is tested with a mix of boundaries. The inputs for each test are a range of valid, minimum, maximum, negative and invalid values for the method. The expected response of a passed test can be a correct error response code or seen as the result of node queries. A successful transaction (the transaction reached consensus and was applied to state) can be determined by getting a `TransactionReceipt` or `TransactionRecord`, or can be determined by using queries such as `TokenInfoQuery` or `TokenBalanceQuery` and investigating for the required changes (creations, updates, etc.). The mirror node can also be used to determine if a transaction was successful via its rest API. Error codes are obtained from the response code proto files.
+
+**Transaction properties:**
+
+https://docs.hedera.com/hedera/sdks-and-apis/sdks/token-service/associate-tokens-to-an-account
+
+**TokenAssociate protobufs:**
+
+https://github.com/hashgraph/hedera-protobufs/blob/main/services/token_associate.proto
+
+**Response codes:**
+
+https://github.com/hashgraph/hedera-protobufs/blob/main/services/response_code.proto
+
+**Mirror Node APIs:**
+
+https://docs.hedera.com/hedera/sdks-and-apis/rest-api
+
+## JSON-RPC API Endpoint Documentation
+
+### Method Name
+
+`associateToken`
+
+### Input Parameters
+
+| Parameter Name          | Type                                             | Required/Optional | Description/Notes                                      |
+|-------------------------|--------------------------------------------------|-------------------|--------------------------------------------------------|
+| accountId               | string                                           | optional          | The ID of the account with which to associate a token. |
+| tokenIds                | list<string>                                     | optional          | The IDs of the tokens to associate.                    |
+| commonTransactionParams | [json object](../commonTransactionParameters.md) | optional          |                                                        |
+
+### Output Parameters
+
+| Parameter Name | Type   | Description/Notes                                                                      |
+|----------------|--------|----------------------------------------------------------------------------------------|
+| status         | string | The status of the submitted `TokenAssociateTransaction` (from a `TransactionReceipt`). |
+
+### Additional Notes
+
+The tests contained in this specification will assume that a valid account and a valid token were already successfully created. <CREATED_ACCOUNT_ID> will denote the ID of the account, and <CREATED_ACCOUNT_PRIVATE_KEY> will denote the private key of the account as a DER-encoded hex string. The token shall be created with default values name="testname", symbol="testsymbol", treasuryAccountId=<OPERATOR_ACCOUNT_ID>, and tokenType="ft". <CREATED_TOKEN_ID> will denote the ID of the created token. The account will only need to be created once, but a new token should be created for each test.
+
+## Property Tests
+
+### **Account ID:**
+
+- The ID of the account with which to associate a token.
+
+| Test no | Name                                                                              | Input                                                                                                                                                                        | Expected response                                                                                       | Implemented (Y/N) |
+|---------|-----------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|-------------------|
+| 1       | Associates a token with an account                                                | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID>], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]                                               | The token association succeeds and the token is associated with <CREATED_ACCOUNT_ID>.                   | N                 |
+| 2       | Associates a token with an account with which it is already associated            | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID>], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]                                               | The token association fails with an TOKEN_ALREADY_ASSOCIATED_TO_ACCOUNT response code from the network. | N                 |
+| 3       | Associates a token with an account without signing with the account's private key | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID>]                                                                                                                | The token association fails with an INVALID_SIGNATURE response code from the network.                   | N                 |
+| 4       | Associates a token with an account that doesn't exist                             | accountId="123.456.789", tokenIds=[<CREATED_TOKEN_ID>]                                                                                                                       | The token association fails with an INVALID_ACCOUNT_ID response code from the network.                  | N                 |
+| 5       | Associates a token with an account that is deleted                                | accountId=<DELETED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID>], commonTransactionParams.signers=[<DELETED_ACCOUNT_PRIVATE_KEY>]                                               | The token association fails with an INVALID_ACCOUNT_ID response code from the network.                  | N                 |
+| 6       | Associates a token with an empty account                                          | accountId="", tokenIds=[<CREATED_TOKEN_ID>]                                                                                                                                  | The token association fails with an SDK internal error.                                                 | N                 |
+
+#### JSON Request Example
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 99232,
+  "method": "associateToken",
+  "params": {
+    "accountId": "0.0.2533",
+    "tokenIds": [
+      "0.0.579680",
+      "0.0.90649"
+    ],
+    "commonTransactionParams": {
+      "signers": [
+        "302e020100300506032b65700422042031f8eb3e77a04ebe599c51570976053009e619414f26bdd39676a5d3b2782a1d"
+      ]
+    }
+  }
+}
+```
+
+#### JSON Response Example
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 99232,
+  "result": {
+    "status": "SUCCESS"
+  }
+}
+```
+
+### **Token IDs:**
+
+- The IDs of the tokens to associate.
+
+| Test no | Name                                                             | Input                                                                                                                                                                        | Expected response                                                                                   | Implemented (Y/N) |
+|---------|------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------|-------------------|
+| 1       | Associates no tokens with an account                             | accountId=<CREATED_ACCOUNT_ID>, commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]                                                                              | The token association succeeds and no associations are made.                                        | N                 |
+| 2       | Associates a token that doesn't exist with an account            | accountId=<CREATED_ACCOUNT_ID>, tokenIds=["123.456.789"], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]                                                    | The token association fails with an INVALID_TOKEN_ID response code from the network.                | N                 |
+| 3       | Associates a token that is deleted with an account               | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<DELETED_TOKEN_ID>], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]                                               | The token association fails with an TOKEN_WAS_DELETED response code from the network.               | N                 |
+| 4       | Associates a token that is empty with an account                 | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[""], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]                                                               | The token association fails with an SDK internal error.                                             | N                 |
+| 5       | Associates a token twice with an account                         | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID>, <CREATED_TOKEN_ID>], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]                           | The token association fails with an TOKEN_ID_REPEATED_IN_TOKEN_LIST response code from the network. | N                 |
+| 6       | Associates three valid tokens with an account                    | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID_1>, <CREATED_TOKEN_ID_2>, <CREATED_TOKEN_ID_3>], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>] | The token association succeeds and the tokens are associated with <CREATED_ACCOUNT_ID>.             | N                 |
+| 7       | Associates two valid tokens and an invalid token with an account | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID_1>, <CREATED_TOKEN_ID_2>, "123.456.789"], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]        | The token association fails with an INVALID_TOKEN_ID response code from the network.                | N                 |
+| 8       | Associates two valid tokens and a deleted token with an account  | accountId=<CREATED_ACCOUNT_ID>, tokenIds=[<CREATED_TOKEN_ID_1>, <CREATED_TOKEN_ID_2>, <DELETED_TOKEN_ID>], commonTransactionParams.signers=[<CREATED_ACCOUNT_PRIVATE_KEY>]   | The token association fails with an TOKEN_WAS_DELETED response code from the network.               | N                 |
+
+#### JSON Request Example
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 99232,
+  "method": "associateToken",
+  "params": {
+    "accountId": "0.0.2533",
+    "tokenIds": [
+      "0.0.579680",
+      "0.0.90649"
+    ],
+    "commonTransactionParams": {
+      "signers": [
+        "302e020100300506032b65700422042031f8eb3e77a04ebe599c51570976053009e619414f26bdd39676a5d3b2782a1d"
+      ]
+    }
+  }
+}
+```
+
+#### JSON Response Example
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 99232,
+  "result": {
+    "status": "SUCCESS"
+  }
+}
+```