swipe_actions/src/main/java/com/testsigma/addons/ios/SwipeInsideElement.java (2)

66-69: 💤 Low value

Edge coordinates may land outside element bounds.

Using rect.x + rect.width and rect.y + rect.height computes coordinates that are technically 1 pixel outside the element. For an element at x=10, width=100, the rightmost pixel inside is 109, but this yields 110. While touch gestures typically have tolerance, consider subtracting 1 (or adding a small inset) for strict within-bounds behavior.

Suggested fix with 1-pixel inset

             int left    = rect.x;
-            int right   = rect.x + rect.width;
+            int right   = rect.x + rect.width - 1;
             int top     = rect.y;
-            int bottom  = rect.y + rect.height;
+            int bottom  = rect.y + rect.height - 1;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@swipe_actions/src/main/java/com/testsigma/addons/ios/SwipeInsideElement.java`
around lines 66 - 69, The edge coordinate calculations in SwipeInsideElement
(where left/right/top/bottom are computed from
rect.x/rect.y/rect.width/rect.height) can produce coordinates one pixel outside
the element; update the computation to inset the bounds (e.g., right = rect.x +
rect.width - 1 and bottom = rect.y + rect.height - 1 or apply a small
configurable inset) so all generated touch points are strictly inside the
element, and adjust any dependent calculations in the same class/method to use
these inset values.

---

111-129: ⚖️ Poor tradeoff

resolveCoordinates is duplicated across multiple action classes.

This exact method is repeated in ScrollInsideElementWithDuration (both iOS and Android). Consider extracting it to a shared utility class to reduce duplication and simplify future maintenance.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@swipe_actions/src/main/java/com/testsigma/addons/ios/SwipeInsideElement.java`
around lines 111 - 129, The resolveCoordinates method is duplicated across
SwipeInsideElement and the ScrollInsideElementWithDuration implementations (iOS
and Android); extract the logic into a single shared utility class (e.g.,
ElementSwipeUtils.resolveCoordinates) as a public static method that accepts
(String dir, int left, int right, int top, int bottom, int cx, int cy) and
returns the int[]; then replace the duplicate implementations in
SwipeInsideElement and both ScrollInsideElementWithDuration classes to call
ElementSwipeUtils.resolveCoordinates(...) and remove the redundant methods.

swipe_actions/pom.xml (2)

36-46: ⚡ Quick win

Mixed test frameworks: both JUnit Jupiter and TestNG are declared.

Having both junit-jupiter-api (test scope) and testng (compile scope) increases complexity. If TestNG is required by the Testsigma SDK at runtime, consider adding a clarifying comment. Otherwise, remove the unused framework.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@swipe_actions/pom.xml` around lines 36 - 46, The pom currently declares both
junit-jupiter-api and testng which mixes test frameworks; either remove the
unused <artifactId>testng</artifactId> dependency or explicitly document and
constrain it (e.g., change its scope to test or add a clarifying comment) if a
runtime component like the Testsigma SDK requires TestNG. Locate the dependency
blocks for junit-jupiter-api and testng and either delete the testng dependency
or set its scope to test and add a comment explaining why TestNG is needed to
avoid confusion.

---

17-17: ⚡ Quick win

JUnit Jupiter 5.8.0-M1 is a milestone (pre-release) version.

Consider using a stable release (e.g., 5.10.x or 5.11.x) for production code.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@swipe_actions/pom.xml` at line 17, The POM currently pins
junit.jupiter.version to a pre-release milestone (junit.jupiter.version =
5.8.0-M1); update that Maven property to a stable JUnit Jupiter release (for
example set junit.jupiter.version to a current stable like 5.10.x or 5.11.x),
then ensure any junit-jupiter dependencies use that property so the build uses
the stable release instead of the milestone.

swipe_actions/src/main/java/com/testsigma/addons/ios/ScrollInsideElementFromMiddleToBottom.java (1)

42-45: 💤 Low value

Same edge coordinate note applies here.

Line 45 uses rect.y + rect.height, which is 1 pixel past the bottom edge. See comment in SwipeInsideElement.java for the suggested fix pattern.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@swipe_actions/src/main/java/com/testsigma/addons/ios/ScrollInsideElementFromMiddleToBottom.java`
around lines 42 - 45, The endY calculation in
ScrollInsideElementFromMiddleToBottom (where startX, startY, endX, endY are
computed) uses rect.y + rect.height which is one pixel past the bottom edge;
change the endY computation to use the bottom edge minus one (e.g., rect.y +
rect.height - 1 or rect.getMaxY() - 1) so the swipe target is inside the element
rather than just outside it.

swipe_actions/src/main/java/com/testsigma/addons/android/ScrollInsideElementWithDuration.java (1)

1-145: ⚖️ Poor tradeoff

Near-complete duplication with the iOS counterpart.

This class is almost identical to ios/ScrollInsideElementWithDuration.java, differing only in the parent class (AndroidAction vs IOSAction) and ApplicationType. If the SDK permits, consider extracting shared logic (duration parsing, coordinate resolution, swipe execution) into a common base class or utility to reduce maintenance burden.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@swipe_actions/src/main/java/com/testsigma/addons/android/ScrollInsideElementWithDuration.java`
around lines 1 - 145, This class duplicates logic from
ios/ScrollInsideElementWithDuration.java; extract the shared behavior (duration
parsing, resolveCoordinates, pointer/sequence swipe construction and common
logging/result handling) into a single reusable base or utility (e.g.,
ScrollInsideElementBase with methods parseDuration(TestData),
resolveCoordinates(...), and performSwipe(AppiumDriver,
startX,startY,endX,endY,durationSeconds)) and have
ScrollInsideElementWithDuration extend that base (or call the utility) while
keeping only platform-specific bits (the parent action type and ApplicationType
annotation) in the Android and iOS subclasses; update references to elementName,
direction, duration, and driver to use the base/utility methods (retain method
names resolveCoordinates, execute entrypoint in subclasses that delegates to the
base).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes