Skip to content

test: add unit tests for MobileBy factories, GuardClauses, AppiumServiceBuilder validation - #261

Draft
Dor-bl wants to merge 1 commit into
mainfrom
test/mobileby-guardclauses-servicebuilder-tests
Draft

Dor-bl wants to merge 1 commit into
mainfrom
test/mobileby-guardclauses-servicebuilder-tests

Conversation

@Dor-bl

@Dor-bl Dor-bl commented Sep 17, 2026

Copy link
Copy Markdown
Owner

PR title

test: add unit tests for MobileBy factories, GuardClauses, AppiumServiceBuilder validation

Related issue

Closes # n/a

List of changes

  • Add test/integration/Common/MobileByFactoryTest.cs: covers MobileBy.AndroidDataMatcher, AndroidViewMatcher, WindowsAutomation, TizenAutomation static factory methods (type/ToString() checks, dispatch to the matching finder interface via a fake ISearchContext, and the InvalidCastException fallback path). These factory methods had zero test references anywhere in the suite — only the underlying By* classes were exercised directly (e.g. in ElementTestEspresso.cs).
  • Add test/integration/Common/GuardClausesTest.cs: covers RequireNotNull, RequireIsPositive, RequirePercentage happy-path and exception-path (including ParamName).
  • Add test/integration/Common/AppiumServiceBuilderValidationTest.cs: covers AppiumServiceBuilder.UsingDriverExecutable and WithEnvironment argument validation (null args, missing file, empty dict keys/values, and the happy-path fluent chaining).

Types of changes

  • New test coverage (non-breaking change that adds tests for existing, previously untested functionality)

Tests

  • Unit tests

How they run: These are pure logic tests with no Appium server/device dependency — they build and pass with a plain dotnet test on both net48 and net8.0. Note: they live under the Appium.Net.Integration.Tests.Common namespace, which is not currently matched by either CI job's filter (FullyQualifiedName~Android|FullyQualifiedName~CustomCommand or FullyQualifiedName~IOS). No CI workflow changes are included in this PR — happy to add a filter/job update in a follow-up if desired.

Documentation

  • Not applicable (no user-facing behaviour change, e.g. tests, CI or maintenance only)

Details

Verified locally: dotnet test test/integration/Appium.Net.Integration.Tests.csproj -f net8.0 --filter "FullyQualifiedName~Appium.Net.Integration.Tests.Common" → 25 passed, 0 failed.

…iceBuilder validation

MobileBy.AndroidDataMatcher/AndroidViewMatcher/WindowsAutomation/TizenAutomation,
GuardClauses, and AppiumServiceBuilder.UsingDriverExecutable/WithEnvironment had
no test coverage. These are pure logic and run without any emulator/simulator.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Moderate findings remain regarding CI selection and incomplete MobileBy coverage.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds pure-logic NUnit coverage for MobileBy factories, GuardClauses, and AppiumServiceBuilder validation.

Changes:

  • Tests MobileBy factory output, dispatch, and fallback behavior.
  • Tests GuardClauses valid and invalid inputs.
  • Tests AppiumServiceBuilder validation and fluent chaining.
File summaries
File Summary
test/integration/Common/MobileByFactoryTest.cs Covers MobileBy factories. Four moderate comments remain: missing CI selection (2 votes), incomplete Windows/Tizen dispatch coverage (3 votes), missing selector assertion (1 vote), and missing FindElements fallback coverage (1 vote).
test/integration/Common/GuardClausesTest.cs Covers guard-clause success and exception paths.
test/integration/Common/AppiumServiceBuilderValidationTest.cs Covers builder validation. One moderate comment remains because CI does not select these tests (1 vote).
Review details

Suppressed comments (3)

test/integration/Common/AppiumServiceBuilderValidationTest.cs:23

  • These tests are not selected by any current CI test command: the unit-test workflow filters to AppiumLocalServerLaunchingTest|DirectConnectTest|AppiumClientConfigTest, while the functional jobs only select Android, CustomCommand, or IOS. As a result, this new validation coverage runs only when someone invokes the Common filter locally and can regress without CI detecting it; include the Common tests in the unit-test filter (or add a dedicated job) before relying on this coverage.
    public class AppiumServiceBuilderValidationTest

test/integration/Common/MobileByFactoryTest.cs:83

  • This case verifies the selected finder method but not the selector argument. A regression that forwards the wrong selector would still pass, unlike the DataMatcher test above; also assert that finder.LastSelector equals {'name':'withText'}.
            Assert.That(finder.LastCalledMethod, Is.EqualTo(nameof(IFindByAndroidViewMatcher<IWebElement>.FindElementsByAndroidViewMatcher)));

test/integration/Common/MobileByFactoryTest.cs:92

  • The fallback assertion covers only FindElement; MobileBy.FindElements has a separate unsupported-context branch that is not exercised by this test. Add the corresponding Assert.Throws<InvalidCastException> for by.FindElements(unsupportedContext) so the fallback behavior cannot regress independently.
            Assert.Throws<InvalidCastException>((Action)(() => by.FindElement(unsupportedContext)));
  • Files reviewed: 3/3 changed files
  • Comments generated: 2
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

using OpenQA.Selenium.Appium;
using OpenQA.Selenium.Appium.Interfaces;

namespace Appium.Net.Integration.Tests.Common
Comment on lines +101 to +105
private class FakeFinder : ISearchContext,
IFindByAndroidDataMatcher<IWebElement>,
IFindByAndroidViewMatcher<IWebElement>,
IFindByWindowsUIAutomation<IWebElement>,
IFindByTizenUIAutomation<IWebElement>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants