search

Mapepire-IBMi / mapepire-js

TS client for Db2 for i/Mapepire
Apache License 2.0
9 stars 4 forks source link

Test Plan #17

Open jonnyz32 opened 3 months ago

jonnyz32 commented 3 months ago

Mapepire test cases

  1. Test Case: Connect to Database Test Case ID: TC01 Type: Connect Description: Verify successful connection to the database. Ensure existing connections are implicitly disconnected. Inputs: props: "system=mySystem;uid=user;pwd=password" application: "MyApp" technique: "cli" Expected Outputs: Status Code: 200 OK Response Fields: job: Should return the server job identifier (e.g., "QPADEV0001") Validation Criteria:

  2. Test Case: Connect to Database with Invalid Properties Test Case ID: TC02 Type: Connect Description: Verify that connection fails when invalid connection properties are provided. Inputs: props: "system=invalidSystem;uid=wrongUser;pwd=wrongPassword" application: "MyApp" technique: "cli" Expected Outputs: Status Code: 401 Unauthorized or appropriate error code Response Fields: error: A descriptive error message indicating connection failure (e.g., "Invalid credentials or system not found.") Validation Criteria:

Ensure that the error field provides a clear reason for the connection failure. Confirm that no job identifier is returned.

  1. Test Case: Run CL Command Successfully Test Case ID: TC03 Type: CL Description: Verify that a CL command is executed successfully and returns the correct job log entries.

Preconditions:

A valid database connection must be established. Inputs:

cmd: "WRKACTJOB" Expected Outputs: Status Code: 200 OK Response Fields: data: Should return a list of job log entries related to the executed command. Validation Criteria: Confirm that the data field contains relevant job log entries. Verify that the command was executed successfully by checking the contents of the job log.

  1. Test Case: Run Invalid CL Command Test Case ID: TC04 Type: CL Description: Verify that an invalid CL command returns an appropriate error message and job log.

Preconditions: A valid database connection must be established. Inputs:

cmd: "INVALIDCOMMAND" Expected Outputs: Status Code: 400 Bad Request or appropriate error code Response Fields: error: A descriptive error message indicating the failure of the command. data: Should return job log entries indicating the nature of the error.

Validation Criteria: Ensure that the error field clearly indicates the reason for the command failure. Verify that the data field contains job log entries corresponding to the error.

  1. Test Case: Connect to Database via TCP Technique Test Case ID: TC05 Type: Connect Description: Verify that the connection can be established using the TCP technique.

Inputs: props: "system=mySystem;uid=user;pwd=password" application: "MyApp" technique: "tcp" job: "" Expected Outputs: Status Code: 200 OK Response Fields: job: Should return the server job identifier. Validation Criteria: Verify that the connection is successfully established using the TCP technique. Confirm that the job field is populated with a valid job identifier.

  1. Test Case: Implicit Disconnection on New Connect Request Test Case ID: TC06 Type: Connect Description: Verify that making a new connection request from the same client implicitly disconnects any existing connection.

Preconditions:

A valid database connection must be established. Inputs: props: "system=mySystem;uid=user;pwd=password" application: "MyApp" technique: "cli" job: "" Expected Outputs:

Status Code: 200 OK Response Fields: job: A new server job identifier. Validation Criteria: Confirm that the job identifier returned differs from the previous connection, indicating an implicit disconnection. Ensure that no errors are reported in the response.

Test Cases for SQL Request

  1. Test Case: Run a Simple SQL Query Test Case ID: TC01 Type: SQL Description: Verify that a simple SQL SELECT statement is executed successfully and returns the correct data.

Inputs: sql: "SELECT * FROM QGPL.TEST_TABLE" rows: 10 terse: false Expected Outputs:

Status Code: 200 OK Response Fields: metadata: Contains column metadata (e.g., column names, data types). data: Contains up to 10 rows of data from QGPL.TEST_TABLE. is_done: true if all rows have been fetched, false if more rows are available. Validation Criteria: Verify that the metadata field correctly describes the result set. Confirm that the data field contains the expected rows. Check that is_done is true when the result set contains 10 or fewer rows.

  1. Test Case: Run an SQL Query with Large Dataset Test Case ID: TC02 Type: SQL Description: Verify that the API handles large result sets by returning only the specified number of rows on the first request.

Inputs: sql: "SELECT * FROM QGPL.LARGE_TABLE" rows: 50 terse: false Expected Outputs:

Status Code: 200 OK Response Fields: metadata: Contains column metadata for QGPL.LARGE_TABLE. data: Contains the first 50 rows of the result set. is_done: false if there are more rows available, true if the entire dataset has been returned. Validation Criteria:

Ensure that only the specified number of rows (50) is returned in the data field. Confirm that is_done is false if more rows are available. Check that subsequent requests can retrieve additional rows until is_done is true.

  1. Test Case: Run an SQL Query in Terse Format Test Case ID: TC03 Type: SQL Description: Verify that the SQL query results are returned in terse format when requested.

Inputs: sql: "SELECT * FROM QGPL.TEST_TABLE" rows: 5 terse: true Expected Outputs: Status Code: 200 OK Response Fields: metadata: Contains column metadata in a compact format. data: Contains 5 rows of data in terse format. is_done: true if all rows have been fetched, false if more rows are available. Validation Criteria:

Confirm that the metadata and data fields are returned in terse format, reducing data verbosity. Ensure that the data field still accurately represents the expected rows.

  1. Test Case: Run an Invalid SQL Query Test Case ID: TC04 Type: SQL Description: Verify that an invalid SQL query returns an appropriate error message. Inputs: sql: "SELECT * FROM NON_EXISTENT_TABLE" rows: 10 terse: false Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: error: A descriptive error message indicating the reason for the query failure. Validation Criteria:

Ensure that the error field provides a clear and descriptive message regarding the invalid query. Verify that no data or metadata fields are returned.

  1. Test Case: Run an SQL Query with Edge Case Inputs Test Case ID: TC05 Type: SQL Description: Verify that the API handles edge case inputs such as an empty sql string or rows set to 0.

Inputs:

sql: "" rows: 0 terse: false Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: error: A descriptive error message indicating the nature of the invalid input. Validation Criteria:

Ensure that the error field clearly explains why the input is invalid. Confirm that the API gracefully handles edge cases without crashing or returning unexpected results.

  1. Test Case: Fetch Remaining Rows of a Large Dataset

Test Case ID: TC06 Type: SQL Description: Verify that the API allows fetching of additional rows after an initial request that did not return the full dataset.

Preconditions:

Initial request returned partial data with is_done set to false. Inputs:

sql: "SELECT * FROM QGPL.LARGE_TABLE" rows: 50 terse: false Expected Outputs:

Status Code: 200 OK Response Fields: metadata: Should match the metadata of the initial request. data: Contains the next set of rows from the result set. is_done: true if all rows have been fetched, otherwise false. Validation Criteria:

Confirm that the subsequent request retrieves additional rows starting from where the last request left off. Ensure that is_done eventually returns true when all data has been fetched.

Test Cases for Prepare SQL Request

  1. Test Case: Prepare a Simple SQL Statement Test Case ID: TC01 Type: prepare_sql Description: Verify that a simple SQL SELECT statement is prepared successfully.

Inputs:

sql: "SELECT * FROM QGPL.TEST_TABLE" terse: false Expected Outputs: Status Code: 200 OK Response Fields: Status: SQL statement is prepared successfully. Statement Handle: A unique identifier for the prepared SQL statement. Validation Criteria:

Confirm that the SQL statement is prepared without errors. Ensure that a valid statement handle is returned for future execution.

  1. Test Case: Prepare SQL Statement in Terse Format Test Case ID: TC02 Type: prepare_sql Description: Verify that the SQL statement is prepared and returns metadata in terse format.

Inputs:

sql: "SELECT * FROM QGPL.TEST_TABLE WHERE COLUMN1 = ?" terse: true Expected Outputs:

Status Code: 200 OK Response Fields: Status: SQL statement is prepared successfully. Metadata: Metadata returned in terse format. Statement Handle: A unique identifier for the prepared SQL statement. Validation Criteria:

Ensure that the terse format reduces verbosity while retaining necessary information. Verify that the metadata accurately describes the prepared statement.

  1. Test Case: Prepare an Invalid SQL Statement Test Case ID: TC03 Type: prepare_sql Description: Verify that an invalid SQL statement returns an appropriate error message.

Inputs:

sql: "SELECT * FROM NON_EXISTENT_TABLE" terse: false Expected Outputs:

Status Code: 400 Bad Request or appropriate error code

Response Fields: Error: A descriptive error message indicating why the SQL statement could not be prepared. Validation Criteria:

Ensure that the error message clearly explains the issue with the SQL statement. Confirm that no statement handle is returned.

  1. Test Case: Prepare SQL Statement with No Terse Option Provided Test Case ID: TC04 Type: prepare_sql Description: Verify the default behavior when the terse option is not provided.

Inputs:

sql: "SELECT * FROM QGPL.TEST_TABLE WHERE COLUMN1 = ?" Expected Outputs:

Status Code: 200 OK Response Fields: Status: SQL statement is prepared successfully. Metadata: Metadata is returned in the default format. Statement Handle: A unique identifier for the prepared SQL statement. Validation Criteria:

Verify that the default format (non-terse) is used for metadata when terse is not specified. Ensure that the statement handle is returned and valid.

  1. Test Case: Prepare a Complex SQL Statement Test Case ID: TC05 Type: prepare_sql Description: Verify that a complex SQL statement involving joins, subqueries, and functions is prepared successfully.

Inputs:

sql: "SELECT A.COL1, B.COL2 FROM QGPL.TABLE_A A JOIN QGPL.TABLE_B B ON A.ID = B.ID WHERE A.COL3 IN (SELECT COL3 FROM QGPL.TABLE_C)" terse: false Expected Outputs:

Status Code: 200 OK Response Fields: Status: SQL statement is prepared successfully. Metadata: Metadata reflecting the complex SQL statement. Statement Handle: A unique identifier for the prepared SQL statement. Validation Criteria: Ensure that the complex SQL statement is prepared without errors. Verify that the metadata accurately reflects the structure of the prepared SQL statement.

  1. Test Case: Prepare SQL with Edge Case Inputs Test Case ID: TC06 Type: prepare_sql Description: Verify that the API handles edge cases such as an empty sql string.

Inputs: sql: "" terse: false Expected Outputs: Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating why the SQL statement could not be prepared. Validation Criteria: Ensure that the API returns an appropriate error message for empty SQL input. Confirm that no statement handle is returned.

Test Cases for Execute SQL Request

  1. Test Case: Execute Prepared SQL Statement Test Case ID: TC01 Type: execute Description: Verify that a prepared SQL statement is executed successfully using a valid cont_id.

Inputs:

cont_id: "valid-prepared-statement-id" batch: false parameters: ["value1", "value2"] Expected Outputs:

Status Code: 200 OK Response Fields: data: Resulting data from the executed SQL statement. Validation Criteria:

Confirm that the SQL statement executes successfully and returns the expected results. Ensure that the returned data matches the expected output based on the SQL statement.

  1. Test Case: Execute SQL Statement in Batch Mode Test Case ID: TC02 Type: execute Description: Verify that multiple SQL operations can be added to a batch and executed together.

Inputs:

cont_id: "valid-prepared-statement-id" batch: true parameters: [["value1a", "value2a"], ["value1b", "value2b"]] Expected Outputs:

Status Code: 200 OK Response Fields: data: Combined result set from all SQL operations in the batch. Validation Criteria:

Ensure that all operations in the batch are executed successfully. Verify that the returned data includes results from all executed SQL statements.

  1. Test Case: Execute SQL with Missing cont_id Test Case ID: TC03 Type: execute Description: Verify that an error is returned when the cont_id is missing.

Inputs:

cont_id: "" batch: false parameters: ["value1"] Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that cont_id is required. Validation Criteria:

Ensure that the error message clearly states that cont_id is missing. Confirm that no data is returned.

  1. Test Case: Execute SQL with Invalid cont_id Test Case ID: TC04 Type: execute Description: Verify that an appropriate error is returned when an invalid cont_id is provided.

Inputs:

cont_id: "invalid-prepared-statement-id" batch: false parameters: ["value1"] Expected Outputs:

Status Code: 404 Not Found or appropriate error code Response Fields: Error: A descriptive error message indicating that the prepared SQL statement was not found. Validation Criteria:

Ensure that the error message clearly explains that the provided cont_id is invalid. Confirm that no data is returned.

  1. Test Case: Execute SQL in Batch Mode without Parameters Test Case ID: TC05 Type: execute Description: Verify that executing in batch mode without parameters executes the batch correctly.

Inputs:

cont_id: "valid-prepared-statement-id" batch: true parameters: [] Expected Outputs:

Status Code: 200 OK Response Fields: data: Resulting data from the executed batch of SQL operations. Validation Criteria:

Confirm that the batch is executed even when no parameters are specified. Ensure that the returned data matches the expected output based on the SQL operations in the batch.

  1. Test Case: Execute SQL with Empty Parameter Array Test Case ID: TC06 Type: execute Description: Verify that an error is returned when parameters are specified incorrectly in batch mode.

Inputs:

cont_id: "valid-prepared-statement-id" batch: true parameters: [[]] Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that parameters must not be empty. Validation Criteria:

Ensure that the error message clearly states that empty parameter arrays are invalid. Confirm that no data is returned.

  1. Test Case: Execute SQL Statement with Mixed Parameters Test Case ID: TC07 Type: execute Description: Verify that SQL operations with mixed parameters execute correctly in batch mode.

Inputs:

cont_id: "valid-prepared-statement-id" batch: true parameters: [["value1a", "value2a"], ["value1b"]] Expected Outputs:

Status Code: 200 OK Response Fields: data: Combined result set from all SQL operations in the batch. Validation Criteria:

Ensure that all SQL operations in the batch execute successfully, regardless of the number of parameters. Verify that the returned data includes results from all executed SQL statements, with proper handling of missing parameters where applicable.

Test Cases for Prepare and Execute SQL Request

  1. Test Case: Prepare and Execute Valid SQL Statement Test Case ID: TC01 Type: prepare_sql_execute Description: Verify that a valid SQL statement is prepared and executed successfully.

Inputs:

parameters: ["value1", "value2"] terse: false Expected Outputs:

Status Code: 200 OK Response Fields: data: Resulting data from the executed SQL statement. Validation Criteria:

Confirm that the SQL statement executes successfully and returns the expected results. Ensure that the returned data matches the expected output based on the SQL statement.

  1. Test Case: Prepare and Execute SQL Statement with Missing Parameters Test Case ID: TC02 Type: prepare_sql_execute Description: Verify that an error is returned when required parameters are missing.

Inputs:

parameters: [] terse: false Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that parameters are required. Validation Criteria:

Ensure that the error message clearly states that required parameters are missing. Confirm that no data is returned.

  1. Test Case: Prepare and Execute SQL with Invalid Parameters Test Case ID: TC03 Type: prepare_sql_execute Description: Verify that an error is returned when invalid parameter types are provided.

Inputs:

parameters: [123, true] // Assuming SQL expects strings terse: false Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that parameters must be of valid types. Validation Criteria:

Ensure that the error message clearly explains that the provided parameters are invalid. Confirm that no data is returned.

  1. Test Case: Prepare and Execute SQL in Terse Format Test Case ID: TC04 Type: prepare_sql_execute Description: Verify that the SQL statement can be executed and the results returned in terse format.

Inputs:

parameters: ["value1", "value2"] terse: true Expected Outputs:

Status Code: 200 OK Response Fields: data: Resulting data in terse format from the executed SQL statement. Validation Criteria:

Confirm that the SQL statement executes successfully and returns the expected results in terse format. Ensure that the returned data matches the expected output based on the SQL statement.

  1. Test Case: Prepare and Execute SQL Statement with No Parameters Test Case ID: TC05 Type: prepare_sql_execute Description: Verify that a SQL statement can be prepared and executed without parameters if the statement does not require them.

Inputs:

parameters: [] terse: false Expected Outputs:

Status Code: 200 OK Response Fields: data: Resulting data from the executed SQL statement. Validation Criteria:

Ensure that the SQL statement executes successfully without any parameters if allowed. Verify that the returned data matches the expected output.

  1. Test Case: Prepare and Execute SQL Statement with Large Parameter Array Test Case ID: TC06 Type: prepare_sql_execute Description: Verify that a SQL statement can be prepared and executed with a large array of parameters.

Inputs:

parameters: ["value1", "value2", "value3", "value4", "value5", ...] // Large array terse: false Expected Outputs:

Status Code: 200 OK Response Fields: data: Resulting data from the executed SQL statement. Validation Criteria:

Confirm that the SQL statement executes successfully with the large array of parameters. Ensure that the returned data matches the expected output based on the SQL statement.

  1. Test Case: Prepare and Execute SQL Statement with SQL Syntax Error Test Case ID: TC07 Type: prepare_sql_execute Description: Verify that an error is returned when the SQL statement has a syntax error.

Inputs:

parameters: ["value1", "value2"] terse: false Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that there is a syntax error in the SQL statement. Validation Criteria:

Ensure that the error message clearly states that there is a syntax error in the SQL statement. Confirm that no data is returned.

Test Cases for SQL More Request

  1. Test Case: Fetch More Rows from a Valid Request Test Case ID: TC01 Type: sqlmore Description: Verify that more rows can be fetched successfully from a previous valid SQL request.

Inputs:

cont_id: "valid_request_id" // Valid request ID from a previous SQL request rows: 10 // Maximum number of rows to return Expected Outputs:

Status Code: 200 OK Response Fields: data: Array of the next set of data rows. is_done: false (indicating more rows are available) Validation Criteria:

Confirm that the response contains the expected data and the is_done field indicates more rows are available. Ensure that the number of rows returned does not exceed the specified limit.

  1. Test Case: Fetch More Rows with Invalid Request ID Test Case ID: TC02 Type: sqlmore Description: Verify that an error is returned when an invalid request ID is provided.

Inputs:

cont_id: "invalid_request_id" // Invalid request ID rows: 10 Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that the request ID is invalid. Validation Criteria:

Ensure that the error message clearly states that the request ID is not valid. Confirm that no data is returned.

  1. Test Case: Fetch More Rows When All Rows Have Been Fetched Test Case ID: TC03 Type: sqlmore Description: Verify that the response indicates no more rows are available when all rows have been fetched.

Inputs:

cont_id: "request_id_all_fetched" // Valid request ID where all rows have been fetched rows: 10 Expected Outputs:

Status Code: 200 OK Response Fields: data: [] (empty array, indicating no more data) is_done: true (indicating that all rows have been fetched) Validation Criteria:

Confirm that the response data is an empty array and the is_done field is set to true. Ensure that the API correctly identifies that there are no more rows to fetch.

  1. Test Case: Fetch More Rows with Zero Limit Test Case ID: TC04 Type: sqlmore Description: Verify that an error is returned when the maximum number of rows to return is zero.

Inputs:

cont_id: "valid_request_id" // Valid request ID from a previous SQL request rows: 0 // Maximum number of rows to return Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that the number of rows must be greater than zero. Validation Criteria:

Ensure that the error message clearly states that the number of rows requested must be greater than zero. Confirm that no data is returned.

  1. Test Case: Fetch More Rows with Negative Row Limit Test Case ID: TC05 Type: sqlmore Description: Verify that an error is returned when a negative maximum number of rows is specified.

Inputs:

cont_id: "valid_request_id" // Valid request ID from a previous SQL request rows: -5 // Invalid number of rows Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that the number of rows must be a positive integer. Validation Criteria:

Ensure that the error message clearly states that the number of rows requested must be a positive integer. Confirm that no data is returned.

  1. Test Case: Fetch More Rows with Large Row Limit Test Case ID: TC06 Type: sqlmore Description: Verify that more rows can be fetched with a large row limit.

Inputs:

cont_id: "valid_request_id" // Valid request ID from a previous SQL request rows: 1000 // Maximum number of rows to return Expected Outputs:

Status Code: 200 OK Response Fields: data: Array containing up to 1000 rows of data. is_done: false (indicating more rows are available, or true if all rows are fetched) Validation Criteria:

Confirm that the response contains the expected number of data rows without exceeding the specified limit. Ensure that the is_done field reflects whether more rows are available.

  1. Test Case: Fetch More Rows with Empty Previous Request Test Case ID: TC07 Type: sqlmore Description: Verify that an error is returned when trying to fetch more rows from a previous request that returned no data.

Inputs:

cont_id: "request_id_no_data" // Valid request ID from a previous SQL request that returned no data rows: 10 Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that no data is available to fetch. Validation Criteria:

Ensure that the error message clearly states that there are no rows available to fetch from the previous request. Confirm that no data is returned.

Test Cases SQL Close Request

  1. Test Case: Successfully Close a Cursor Test Case ID: TC01 Type: sqlclose Description: Verify that a cursor can be closed successfully using a valid request ID.

Inputs:

cont_id: "valid_request_id" // Valid request ID from a previous SQL/prepare_sql/prepare_sql_execute request Expected Outputs:

Status Code: 200 OK Response Fields: data: Confirmation message indicating that the cursor has been closed successfully. Validation Criteria:

Confirm that the response indicates successful closure of the cursor. Ensure that subsequent requests using the same cont_id return an error indicating the cursor is closed.

  1. Test Case: Close Cursor with Invalid Request ID Test Case ID: TC02 Type: sqlclose Description: Verify that an error is returned when an invalid request ID is provided.

Inputs:

cont_id: "invalid_request_id" // Invalid request ID Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that the request ID is invalid. Validation Criteria:

Ensure that the error message clearly states that the request ID is not valid. Confirm that no data is returned.

  1. Test Case: Close Cursor That is Already Closed Test Case ID: TC03 Type: sqlclose Description: Verify that an error is returned when trying to close a cursor that has already been closed.

Inputs:

cont_id: "already_closed_request_id" // Valid request ID from a previous SQL operation where the cursor has already been closed Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that the cursor is already closed. Validation Criteria:

Confirm that the error message states that the cursor has already been closed. Ensure that no data is returned.

  1. Test Case: Close Cursor with Empty Request ID Test Case ID: TC04 Type: sqlclose Description: Verify that an error is returned when an empty request ID is provided.

Inputs:

cont_id: "" // Empty request ID Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that the request ID cannot be empty. Validation Criteria:

Ensure that the error message clearly states that the request ID cannot be empty. Confirm that no data is returned.

  1. Test Case: Close Cursor with Null Request ID Test Case ID: TC05 Type: sqlclose Description: Verify that an error is returned when a null request ID is provided.

Inputs:

cont_id: null // Null request ID Expected Outputs:

Status Code: 400 Bad Request or appropriate error code Response Fields: Error: A descriptive error message indicating that the request ID cannot be null. Validation Criteria:

Ensure that the error message clearly states that the request ID cannot be null. Confirm that no data is returned.

  1. Test Case: Close Cursor with Non-Existent Request ID Test Case ID: TC06 Type: sqlclose Description: Verify that an error is returned when attempting to close a cursor with a non-existent request ID.

Inputs:

cont_id: "non_existent_request_id" // Non-existent request ID Expected Outputs:

Status Code: 404 Not Found or appropriate error code Response Fields: Error: A descriptive error message indicating that the request ID does not exist. Validation Criteria:

Ensure that the error message clearly states that the request ID does not exist. Confirm that no data is returned.

  1. Test Case: Close Cursor with Multiple Requests Test Case ID: TC07 Type: sqlclose Description: Verify that closing a cursor does not affect the ability to close the same cursor from different requests.

Inputs:

cont_id: "valid_request_id" // Valid request ID from a previous SQL operation Expected Outputs:

Status Code: 200 OK for the first close request. Status Code: 400 Bad Request or appropriate error code for the subsequent close request. Response Fields: First close request: data: Confirmation message indicating successful closure. Second close request: Error: A message indicating the cursor is already closed. Validation Criteria:

Confirm that the first close request is successful. Ensure that the second close request returns an error indicating the cursor is already closed.

worksofliam commented 3 months ago

@ajshedivy Is this something you will be using for the py client tests? I wonder if this issue should be a nicely formatted page in the docs.

ajshedivy commented 3 months ago

@ajshedivy Is this something you will be using for the py client tests? I wonder if this issue should be a nicely formatted page in the docs.

yes working on that now!