feat/TE-29060-Added already present code to if condition #205
Conversation
WalkthroughThis change introduces a new Java-based automation add-on, "date_compare_with_format," for the Testsigma platform. It includes Maven project configuration, resource properties, and multiple new action classes for Android, iOS, and Web platforms, enabling date comparison operations using customizable formats and operators. No modifications to existing code are present. Changes
Sequence Diagram(s)sequenceDiagram
participant TestSigmaPlatform
participant ActionClass
participant DateParser
TestSigmaPlatform->>ActionClass: Invoke execute() with test data
ActionClass->>DateParser: Parse date1 using format
ActionClass->>DateParser: Parse date2 using format
ActionClass->>ActionClass: Compare dates with operator
alt Comparison success
ActionClass->>TestSigmaPlatform: Return success result
else Comparison failure or error
ActionClass->>TestSigmaPlatform: Return failure result with message
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15–20 minutes Suggested reviewers
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (1)
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/IfConditionCompareDateUsingFormat.java (1)
1-100: Code duplication across platform implementations.This Web implementation suffers from the same code duplication issue as the Android and iOS versions. The same refactoring suggestion applies here.
🧹 Nitpick comments (9)
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/android/CompareDateUsingFormat.java (2)
6-6: Remove unused import.The
WebActionimport is not used in this Android action class.-import com.testsigma.sdk.WebAction;
41-41: Consider thread safety for SimpleDateFormat.
SimpleDateFormatis not thread-safe. While this may not be an immediate issue in this context, consider usingDateTimeFormatterfor better thread safety and modern Java practices.-SimpleDateFormat sdf = new SimpleDateFormat(dateFormat); +DateTimeFormatter formatter = DateTimeFormatter.ofPattern(dateFormat);Note: This would require updating the parsing logic to use
LocalDateTime.parse()or similar methods.date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/ios/CompareDateUsingFormat.java (2)
6-6: Remove unused import.The
WebActionimport is not used in this iOS action class.-import com.testsigma.sdk.WebAction;
41-41: Consider thread safety for SimpleDateFormat.Same thread safety concern as noted in the Android version - consider using
DateTimeFormatterfor better practices.date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/CompareDateUsingFormat.java (1)
81-81: Remove debug text from production error message.The "Else part" text appears to be debug information and should be removed from the production error message.
- logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString+" Else part"); + logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString);date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/ios/IfConditionCompareDateUsingFormat.java (1)
80-80: Remove debug text from log message.The log message contains "+ Else part" which appears to be leftover debug text and should be removed for cleaner, more professional logging.
- logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString+" Else part"); + logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString);date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/android/IfConditionCompareDateUsingFormat.java (1)
80-80: Remove debug text from log message.Same issue as in the iOS version - the log message contains leftover debug text "+ Else part" that should be removed.
- logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString+" Else part"); + logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString);date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/IfConditionCompareDateUsingFormat.java (2)
46-97: Standardize Result type usage for consistency.There's inconsistent usage of
Resultvscom.testsigma.sdk.Resultthroughout the method. SinceResultis already imported (line 4), use the shorter form consistently.- com.testsigma.sdk.Result result = com.testsigma.sdk.Result.SUCCESS; + Result result = Result.SUCCESS;- return com.testsigma.sdk.Result.FAILED; + return Result.FAILED;- result = com.testsigma.sdk.Result.FAILED; + result = Result.FAILED;- result = com.testsigma.sdk.Result.FAILED; + result = Result.FAILED;
83-83: Remove debug text from log message.Same debug text issue exists here as in the other platform implementations.
- logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString+" Else part"); + logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
date_compare_with_format/pom.xml(1 hunks)date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/android/CompareDateUsingFormat.java(1 hunks)date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/android/IfConditionCompareDateUsingFormat.java(1 hunks)date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/ios/CompareDateUsingFormat.java(1 hunks)date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/ios/IfConditionCompareDateUsingFormat.java(1 hunks)date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/CompareDateUsingFormat.java(1 hunks)date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/IfConditionCompareDateUsingFormat.java(1 hunks)date_compare_with_format/src/main/resources/testsigma-sdk.properties(1 hunks)
🔇 Additional comments (6)
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/android/CompareDateUsingFormat.java (1)
51-71: LGTM! Well-structured switch statement with proper validation.The operator validation and comparison logic is correctly implemented with appropriate error handling for invalid operators.
date_compare_with_format/pom.xml (1)
24-70: LGTM! Well-structured dependency configuration.The Maven configuration is appropriate for a TestSigma addon with proper dependencies for multi-platform support (Android, iOS, Web).
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/CompareDateUsingFormat.java (1)
41-41: Good practice: strict date parsing enabled.The addition of
sdf.setLenient(false)is excellent as it ensures strict date validation and prevents unexpected parsing behavior.date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/ios/IfConditionCompareDateUsingFormat.java (3)
14-29: Class structure and annotations are well-configured.The class properly extends
IOSAction, uses appropriate annotations for TestSigma SDK integration, and correctly defines the test data parameters with proper validation constraints.
39-71: Date parsing and comparison logic is correctly implemented.The use of
SimpleDateFormatwithsetLenient(false)ensures strict date parsing, and the comparison logic usingDate.compareTo()with the switch statement properly handles all supported operators.
84-93: Error handling is comprehensive and well-structured.The exception handling properly catches
ParseExceptionfor date parsing issues and includes a generic exception handler with detailed logging usingExceptionUtils.
| <artifactId>testng</artifactId> | ||
| <version>6.14.3</version> | ||
| </dependency> |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify TestNG version for security vulnerabilities.
TestNG version 6.14.3 is quite old (released in 2018). Please verify it doesn't have known security vulnerabilities.
🌐 Web query:
Are there any known security vulnerabilities in TestNG version 6.14.3?
💡 Result:
Yes, TestNG version 6.14.3 has known security vulnerabilities. The most significant is a Path Traversal vulnerability identified as CVE-2022-4065. This issue arises from insufficient input validation in the testngXmlExistsInJar() function within the JarFileUtils.java file of the XML File Parser component. An attacker can exploit this vulnerability by providing a specially crafted XML file, potentially leading to the overwriting of arbitrary files on the system. (cybersecurity-help.cz)
To mitigate this vulnerability, it is recommended to upgrade to TestNG version 7.5.1 or later, as these versions include the necessary security patches. (cybersecurity-help.cz)
Additionally, Snyk has reported other vulnerabilities in TestNG 6.14.3, including:
-
Arbitrary File Write via Archive Extraction (Zip Slip): This medium-severity issue allows attackers to write arbitrary files during archive extraction. It can be addressed by upgrading to TestNG version 7.5.1 or higher. (security.snyk.io)
-
Unsafe Dependency Resolution: This medium-severity vulnerability involves resolving dependencies over insecure channels, potentially exposing the system to man-in-the-middle attacks. Upgrading to TestNG version 7.0.0-beta4 or later mitigates this risk. (security.snyk.io)
Given these vulnerabilities, it's crucial to update to a patched version of TestNG to ensure the security and integrity of your testing framework.
Citations:
- 1: https://www.cybersecurity-help.cz/vdb/SB2023033036?utm_source=openai
- 2: https://www.cybersecurity-help.cz/vdb/SB2023033036?utm_source=openai
- 3: https://security.snyk.io/package/maven/org.testng%3Atestng/6.14.3?utm_source=openai
- 4: https://security.snyk.io/package/maven/org.testng%3Atestng/6.14.3?utm_source=openai
Upgrade TestNG to 7.5.1 or later to remediate critical vulnerabilities
The currently pinned TestNG 6.14.3 is affected by multiple medium–high severity issues, including:
- CVE-2022-4065 (Path Traversal) in
JarFileUtils.javaallows overwriting arbitrary files - Zip Slip / Arbitrary File Write during archive extraction
- Unsafe dependency resolution over insecure channels
All are fixed in TestNG 7.5.1+. Please update your POM:
• File: date_compare_with_format/pom.xml (around lines 44–46)
• Change the TestNG version:
<artifactId>testng</artifactId>
- <version>6.14.3</version>
+ <version>7.5.1</version>After updating, rebuild and verify your test suite passes as expected.
🤖 Prompt for AI Agents
In date_compare_with_format/pom.xml around lines 44 to 46, the TestNG version is
pinned at 6.14.3, which has critical vulnerabilities. Update the version number
to 7.5.1 or later in the dependency declaration. After changing the version,
rebuild the project and run the test suite to ensure everything works correctly.
| package com.qateamtestinge2e.testsigma.addons.android; | ||
|
|
||
| import com.testsigma.sdk.*; | ||
| import com.testsigma.sdk.annotation.Action; | ||
| import com.testsigma.sdk.annotation.TestData; | ||
| import lombok.Data; | ||
| import org.apache.commons.lang3.exception.ExceptionUtils; | ||
| import org.openqa.selenium.NoSuchElementException; | ||
|
|
||
| import java.text.ParseException; | ||
| import java.text.SimpleDateFormat; | ||
| import java.util.Date; | ||
|
|
||
| @Data | ||
| @Action(actionText = "Verify date testdata1 is Equals/Less Than/Greater Than/Greater Than or equals/Less Than or equals testdata2 with date format", | ||
| description = "Verify if one date is equal to, less than, or greater than another date", | ||
| applicationType = ApplicationType.ANDROID, | ||
| actionType = StepActionType.IF_CONDITION, | ||
| useCustomScreenshot = false) | ||
| public class IfConditionCompareDateUsingFormat extends AndroidAction { | ||
| @TestData(reference = "testdata1") | ||
| private com.testsigma.sdk.TestData firstDateTestData; | ||
| @TestData(reference = "testdata2") | ||
| private com.testsigma.sdk.TestData secondDateTestData; | ||
| @TestData(reference = "Equals/Less Than/Greater Than/Greater Than or equals/Less Than or equals" ,allowedValues = {"equals","less than","greater than","greater than or equals","less than or equals"} ) | ||
| private com.testsigma.sdk.TestData operatorTestData; | ||
| @TestData(reference = "date format") | ||
| private com.testsigma.sdk.TestData dateFormatTestData; | ||
|
|
||
| @Override | ||
| protected Result execute() throws NoSuchElementException { | ||
| logger.info("Initiating execution"); | ||
|
|
||
| String firstDateString = firstDateTestData.getValue().toString(); | ||
| String secondDateString = secondDateTestData.getValue().toString(); | ||
| String operator = operatorTestData.getValue().toString().toLowerCase(); | ||
| String dateFormat = dateFormatTestData.getValue().toString(); | ||
|
|
||
| SimpleDateFormat sdf = new SimpleDateFormat(dateFormat); | ||
| sdf.setLenient(false); | ||
|
|
||
|
|
||
| Result result = Result.SUCCESS; | ||
| try { | ||
| Date firstDate = sdf.parse(firstDateString); | ||
| Date secondDate = sdf.parse(secondDateString); | ||
|
|
||
| int comparisonResult = firstDate.compareTo(secondDate); | ||
| boolean isTrue = false; | ||
|
|
||
| switch (operator) { | ||
| case "equals": | ||
| isTrue = comparisonResult == 0; | ||
| break; | ||
| case "less than": | ||
| isTrue = comparisonResult < 0; | ||
| break; | ||
| case "less than or equals": | ||
| isTrue = comparisonResult <= 0; | ||
| break; | ||
| case "greater than": | ||
| isTrue = comparisonResult > 0; | ||
| break; | ||
| case "greater than or equals": | ||
| isTrue = comparisonResult >= 0; | ||
| break; | ||
| default: | ||
| logger.warn("Invalid operator provided."); | ||
| setErrorMessage("Invalid operator provided."); | ||
| return Result.FAILED; | ||
| } | ||
|
|
||
| if (isTrue) { | ||
| result = Result.SUCCESS; | ||
| logger.info("Date comparison successful: " + firstDateString + " " + operator + " " + secondDateString); | ||
| setSuccessMessage("Date comparison successful: " + firstDateString + " " + operator + " " + secondDateString); | ||
|
|
||
| } else { | ||
| result = Result.FAILED; | ||
| logger.info("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString+" Else part"); | ||
| setErrorMessage("Date comparison failed: " + firstDateString + " not " + operator + " " + secondDateString); | ||
|
|
||
| } | ||
| } catch (ParseException e) { | ||
| logger.warn("Exception occurred while comparing dates: " + e.getMessage()); | ||
| setErrorMessage("Please check the given Date format according to the input Date"); | ||
| result = Result.FAILED; | ||
| } | ||
| catch (Exception e) { | ||
| logger.warn("Exception occurred while comparing dates: " + ExceptionUtils.getStackTrace(e)); | ||
| setErrorMessage("Exception occurred while comparing dates. Error: " + ExceptionUtils.getMessage(e)); | ||
| result = Result.FAILED; | ||
| } | ||
| return result; | ||
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider extracting shared logic to reduce code duplication.
This implementation is nearly identical to the iOS version, differing only in the package name and base class. Consider extracting the core date comparison logic into a shared utility class to reduce duplication and improve maintainability.
Create a shared utility class like:
public class DateComparisonUtil {
public static ComparisonResult compareDates(String firstDate, String secondDate,
String operator, String dateFormat) {
// Extract the core logic here
}
}Then use this utility in platform-specific action classes.
🤖 Prompt for AI Agents
In
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/android/IfConditionCompareDateUsingFormat.java
lines 1 to 97, the date comparison logic duplicates the iOS version with only
package and base class differences. To fix this, extract the core date parsing
and comparison logic into a shared utility class (e.g., DateComparisonUtil) with
a static method that accepts the two date strings, operator, and date format,
and returns the comparison result. Then refactor this Android action class to
call that utility method, reducing duplication and improving maintainability.
| @TestData(reference = "Equals/Less Than/Greater Than/Greater Than or equals/Less Than or equals", allowedValues = {"equals/less than/greater than/greater than or equals/less than or equals"}) | ||
| private com.testsigma.sdk.TestData operatorTestData; |
There was a problem hiding this comment.
Fix allowedValues annotation - incorrect format.
The allowedValues should be an array of individual operator strings, not a single concatenated string. This bug would prevent proper operator validation.
-@TestData(reference = "Equals/Less Than/Greater Than/Greater Than or equals/Less Than or equals", allowedValues = {"equals/less than/greater than/greater than or equals/less than or equals"})
+@TestData(reference = "Equals/Less Than/Greater Than/Greater Than or equals/Less Than or equals", allowedValues = {"equals","less than","greater than","greater than or equals","less than or equals"})📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @TestData(reference = "Equals/Less Than/Greater Than/Greater Than or equals/Less Than or equals", allowedValues = {"equals/less than/greater than/greater than or equals/less than or equals"}) | |
| private com.testsigma.sdk.TestData operatorTestData; | |
| @TestData( | |
| reference = "Equals/Less Than/Greater Than/Greater Than or equals/Less Than or equals", | |
| allowedValues = {"equals","less than","greater than","greater than or equals","less than or equals"} | |
| ) | |
| private com.testsigma.sdk.TestData operatorTestData; |
🤖 Prompt for AI Agents
In
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/ios/CompareDateUsingFormat.java
at lines 27-28, the allowedValues annotation is incorrectly formatted as a
single concatenated string. Fix this by splitting the allowedValues into an
array of individual operator strings, each enclosed in quotes and separated by
commas, to enable proper operator validation.
| sdf.setLenient(false); | ||
|
|
||
|
|
||
| com.testsigma.sdk.Result result = com.testsigma.sdk.Result.SUCCESS; |
There was a problem hiding this comment.
Fix inconsistent Result class usage.
The code mixes Result.SUCCESS and com.testsigma.sdk.Result.FAILED inconsistently. Use the imported Result class consistently.
-com.testsigma.sdk.Result result = com.testsigma.sdk.Result.SUCCESS;
+Result result = Result.SUCCESS;- result = Result.SUCCESS;
+ result = Result.SUCCESS;- result = com.testsigma.sdk.Result.FAILED;
+ result = Result.FAILED;- result = com.testsigma.sdk.Result.FAILED;
+ result = Result.FAILED;Also applies to: 75-75, 80-80, 88-88
🤖 Prompt for AI Agents
In
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/CompareDateUsingFormat.java
at lines 44, 75, 80, and 88, the code inconsistently uses the fully qualified
Result class name and the imported Result class. To fix this, replace all
occurrences of `com.testsigma.sdk.Result` with just `Result` to use the imported
class consistently throughout the file.
| return result; | ||
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
Fix syntax error - extra closing brace.
There's an extra closing brace that will cause compilation failure.
- }Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In
date_compare_with_format/src/main/java/com/qateamtestinge2e/testsigma/addons/web/CompareDateUsingFormat.java
at line 98, remove the extra closing brace that is causing a syntax error and
preventing compilation.
| @@ -0,0 +1 @@ | |||
| testsigma-sdk.api.key=eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJlZWIxMmQyYi1mNWRmLTBhZDItNjBkYy02MWUzNjNmZWYwMjMiLCJ1bmlxdWVJZCI6IjQ4NjEiLCJpZGVudGl0eUFjY291bnRVVUlkIjoiNDM1NCJ9.6PQ5dTTwfPil8_sD-wWAbtqg5hp6SEFxQQBNDg73fMzqteKg1PE-EIhVKfMEdvXrUEzgAP1BoXOt1pXboCb7YA No newline at end of file | |||
There was a problem hiding this comment.
Critical security vulnerability: Hardcoded API key exposed in source code.
The JWT token should never be committed to version control as it grants access to the TestSigma platform and can be viewed by anyone with repository access.
Remove the hardcoded key and use environment variables or a secure secrets management system:
-testsigma-sdk.api.key=eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJlZWIxMmQyYi1mNWRmLTBhZDItNjBkYy02MWUzNjNmZWYwMjMiLCJ1bmlxdWVJZCI6IjQ4NjEiLCJpZGVudGl0eUFjY291bnRVVUlkIjoiNDM1NCJ9.6PQ5dTTwfPil8_sD-wWAbtqg5hp6SEFxQQBNDg73fMzqteKg1PE-EIhVKfMEdvXrUEzgAP1BoXOt1pXboCb7YA
+testsigma-sdk.api.key=${TESTSIGMA_API_KEY}Ensure the existing key is revoked and regenerated immediately.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| testsigma-sdk.api.key=eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJlZWIxMmQyYi1mNWRmLTBhZDItNjBkYy02MWUzNjNmZWYwMjMiLCJ1bmlxdWVJZCI6IjQ4NjEiLCJpZGVudGl0eUFjY291bnRVVUlkIjoiNDM1NCJ9.6PQ5dTTwfPil8_sD-wWAbtqg5hp6SEFxQQBNDg73fMzqteKg1PE-EIhVKfMEdvXrUEzgAP1BoXOt1pXboCb7YA | |
| # src/main/resources/testsigma-sdk.properties | |
| testsigma-sdk.api.key=${TESTSIGMA_API_KEY} |
🤖 Prompt for AI Agents
In date_compare_with_format/src/main/resources/testsigma-sdk.properties at line
1, remove the hardcoded API key to prevent security risks. Replace it by
referencing an environment variable or a secure secrets management system to
load the key at runtime. Also, ensure the exposed key is revoked and regenerated
immediately to maintain security.
Addon Name: Date Compare with Format
account : [email protected]
Jarvis Link: https://jarvis.testsigma.com/ui/tenants/34489/addons
Jira : https://testsigma.atlassian.net/browse/TE-29060
Added already present code to if condition
Summary by CodeRabbit
New Features
Chores