Skip to content

welsdarte/MobileAutomation

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

33 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Structure

BasePage and TestCases are the main classes that hold out important test information. All element declarations and actions goes into BasePage class or another class that inherits the BasePage class (CariPage etc.) All action combinations goes into TestCases class or it's child classes

  • to declarate web elements use Xpath and Selenium's FindBy annotation like so:
@FindBy(xpath = "//*[@text='some visible text']")
public WebElement elementName;

or

@FindBy(xpath = "//*[contains(@text,'some text that included by another text')]")
public WebElement elementName;

now you can use these variable to perform simple actions like:

  • elementName.click();
  • elementName.clear();
  • elementName.sendKeys("abc");

AMU Language

AMU stands for Average Mobile User and it is the source code for generating the above structure code in Java. An .amu file consists of 3 parts:

Action

Actions are the command-like smallest code pieces in amu language and used for writing scenarios

ex.

I clicked "Start" then

I typed "pass1234" to "Enter password..."

List of all available actions by now:

Screen Shot 2021-08-24 at 15 04 51

Scenario

Scenarios are basic containers that can contain multiple actions. They are optimization solution for the test cases' length and complexity by reducing recurring code size. A scenario block starts with a unique scenario name (identifier), { actions }

ex.

 loginToApp{
   I clicked "login" then
   I typed "user1" to "username" and
   I typed "pass1" to "password" then
 }

TestCase

TestCases are the final block build with scenarios. On every test case start, app relaunches and returns to its original state (Not full reset).

ex.

canAdd50Cards(
   <loginToApp>
   <addCard:50>
)

TestCase blocks must come after from all the scenarios in the .amu file. General amu code looks like this:

Screen Shot 2021-08-24 at 15 01 58

scenario1{
  action1
  action2
  action3
}
scenario2{
  action1
}

testCase1(
  <scenario1>
  <scenario2>
)
testCase2(
  <scenario2:10>
)

for more:

amuLexer.g4

amuParser.g4

Transpling

The visitor visits the parse tree rules and generate java code fragments like statements declarations etc. Generated codes stored in ArrayLists.

Transpiler takes those Arraylists and create Java code and overwrites it to BasePage and TestCases classes.

If new features will be added to grammar, these files must be revised.

After Transpiler executed all the scenarios becomes java methods in BasePage.java and all the testCases becomes @Test annotations in TestCase.java. If a wanted action not supported by AMU then custom child classes can be created (UploadPhotoPage extends BasePage and UploadCases extends TestCases) and tests can be written mannually according to the above structure.

For manual tests:

About

No description or website provided.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published