Sunday, July 30, 2023

How to identify the main actvity from the AndroidManifest.xml

 When you setup applium capacbilities giving the app package and app activity, you have to give the main activity as the app activity.

Here is how you identify the main activity from AndroidManifest.xml when it has multiple activities.

  • Locate the AndroidManifest.xml:

The AndroidManifest.xml file is located in the app folder of your Android project. The typical path is app/src/main/AndroidManifest.xml.

  • Open the AndroidManifest.xml:

Use a text editor or an XML editor to open the AndroidManifest.xml file.

  • Search for <activity> tags:

Inside the AndroidManifest.xml, look for <activity> tags. Each <activity> tag represents an activity (screen) of the Android application.

  • Find the Main Activity:

The AppActivity is usually the main activity of the app. It is the entry point of the application, and its intent filter is often set to respond to the android.intent.action.MAIN and android.intent.category.LAUNCHER actions.

  • Look for Intent Filters:

Inside the <activity> tags, check for <intent-filter> tags. The AppActivity should have an <intent-filter> that includes the android.intent.action.MAIN and android.intent.category.LAUNCHER actions.

  • Extract the AppActivity Name:

Extract the value of the android:name attribute from the <activity> tag that has the <intent-filter> with the android.intent.action.MAIN and android.intent.category.LAUNCHER actions. The value of android:name attribute will be the AppActivity.

<activity

    android:name=".ui.MainActivity"  <!-- This is the AppActivity -->

    android:label="@string/app_name">

    <intent-filter>

        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />

    </intent-filter>

</activity>


In this example, the AppActivity is .ui.MainActivity.


Friday, March 31, 2023

Hybrid approach to Automation

What does hybrid approach to test automation mean?

It's a strategic approach that aims to support better maintainability and reduce flakiness in end-to-end (E2E) test automation. This approach involves using a combination of API tests and UI tests.

In scenarios where certain prerequisites must be met before attempting the actual test, we can use endpoint calls/API tests to achieve these prerequisites. Then, we can use webdriver tests for UI-level functional validations/assertions.

By using this approach, we can redice the flakiness that may come from  webdriver tests due to delays, object changes, and other issues. This approach is particularly useful for sections of the test case that are outside the main test case.

Let me explain with an example:

In here we are doing a mandatry field validation check; Our featue file is as below;

Scenario: Mandatory fields validation
Given I am a registered user
And I go to the accounts page
And I leave the basic salary field blank
When I try to move to the next page
Then a validation error message is displayed for the basic salary field

My step definition will be like this; 

public class MandatoryFieldsValidationStepDefinitions {

    @Given("I am a registered user")
    public void iAmARegisteredUser() {
        // Code to implement the Creat user step using RestAssured API
        
    }

    @And("I go to the accounts page")
    public void iGoToTheAccountsPage() {
        // Code to implement the "And" step using Appium
        // Navigate to the accounts page using Appium
    }

    @And("I leave the basic salary field blank")
    public void iLeaveTheBasicSalaryFieldBlank() {
        // Code to implement the "And" step using Appium
        // Find the basic salary field element and clear its value
    }

    @When("I try to move to the next page")
    public void iTryToMoveToTheNextPage() {
        // Code to implement the "When" step using Appium
        // Find the "Next" button element and click it
    }

    @Then("a validation error message is displayed for the basic salary field")
    public void aValidationErrorMessageIsDisplayedForTheBasicSalaryField() {
        // Code to implement the "Then" step using Appium
        // Find the error message element for the basic salary field and verify it is displayed
    }
}

So how do we support this in our test framework? Since the CucumberRunner takes care of executing the features by mapping them with the correct step definition, all we have to do is ensure that our design is correct and that relevant API testing and webdriver libraries are included in the project.

A sample automation framework structure for a Maven project is shown below;








Featured

Selenium - Page Object Model and Action Methods

  How we change this code to PageObjectModel and action classes. 1 2 3 driver . findElement ( By . id ( "userEmail" )). sendKeys (...

Popular Posts