Explore topic-wise InterviewSolutions in .

Appium Package master REFERS to a set of tools that are used to create and manage Appium packages. 

To create a new Appium package, we can use the following lines of CODE:

In the above code, we use Gulp (a streaming build system) and the command “create-package” to create a new package. -n SIGNIFIES a new package has to be created and <package-name> signifies the name of the package to be created.

In the above code, we mention --nobabel so as to specify that the command is for regular es5. 

YES, we can USE javascript to INTERACT with applications while RUNNING Appium tests. When we PERFORM the instructions on Appium, the server transmits the script wrapped in an anonymous function to our app, which is then executed.

 Yes, Appium allows testers to execute tests in a multithreaded environment. The only THING they have to worry about is that no more than ONE TEST RUNS against the same Appium server at the same TIME.

On iOS and Android, Appium behaves DIFFERENTLY. Because it is a "cross-platform" tool, a METHOD must be in place to DISTINGUISH between the session requests of the two operating systems. JSON objects, referred to as DESIRED Capabilities, were introduced to address this specific problem statement.

Desired Capabilities are key-value pairs of data that separate the establishment of an Android app testing session from that of an iOS app testing session. With arguments such as platformName, deviceName, appPackage, and appActivity, the server will be able to tell the difference between the two operating systems very quickly.

Appium session is a medium to send commands to a SPECIFIC TEST APPLICATION. Commands are always executed within the context of a session. Before performing any command, a client utilizes the session identifier as the sessionId parameter. A session is requested by the client library from the server. After that, the server will return a sessionId endpoint, which can be used to submit additional commands to interact with the application(s) being tested.

Every 'testing' is included within a session. Given that Appium is a SIMPLE client and server-based method, this is self-evident. Post requests, also known as session requests, are SENT by the client to the server. These queries use the JSON Wire Protocol to communicate and convey information in JSON Object format.

The JSON Wire Protocol is the method by which client and server data are exchanged. It was created by WebDriver's developers. The protocol, according to them, consists of a set of standardised endpoints that are offered to clients VIA a RESTful API. This enables the webdriver to communicate with a server and a client in order to automate tasks. In this protocol, JSON is used to transmit data between the server and the client. Before delivering an object to a server, a client (or the computer running the WebDriver API) turns it into a JSON object. The JSON object is PARSED by the server and converted back to a JavaScript object. The response object is converted to a JSON string by the server and returned to the client. For use, the client transforms the JSON string to a JavaScript object.

In the above IMAGE, we can see the client and the server communicates with each other via JSON wire protocol. The server sends a request to the appium server for running tests and the appium server sends back the response to the main server. 

The mobile JSON Wire Protocol, which is an extension of the Selenium JSON Wire Protocol, is used by Appium. Other than ESTABLISHING up a communication stream, it's used to regulate other mobile phone behaviours.

The practice of testing application SOFTWARE produced for handheld MOBILE devices for functionality, usability, and consistency is known as mobile application testing. Mobile application testing can be done in two ways: automated or manually.

It differs from Mobile Testing, Mobile Testing FOCUSES on native application functionalities of mobile devices such as call, SMS, and media player, among others. Meanwhile, in Mobile Application Testing, we concentrate SOLELY on a specific application's operation and end-to-end features.

End-to-end mobile application test automation is a method of testing a software product from beginning to end to ensure that the application flow is as planned. It establishes the product's system mandates and ensures that all integrated components perform as expected.

The GOAL of end-to-end (E2E) mobile application test automation is to test from the PERSPECTIVE of the end-user by replicating a real-world situation, in which a user uses the application, and confirming the system under test and its components for data INTEGRITY and integration.

These days, software SYSTEMS are sophisticated and integrated with numerous subsystems. The entire software system could fail if one of the subsystem fails. We employ end-to-end mobile application test automation to eliminate this big risk.

Following THINGS should be kept in mind while performing end-to-end mobile testing automation :

• The installation of the application
• Launching the application for the first time without having network access.
• The uninstallation of the application.
• If the application is supported in horizontal mode, the orientation of the application.
• Testing the performance of an application on a variety of devices and network conditions.
• Testing the application's response and how it reacts when a user credential is provided that is invalid.

Appium is an HTTP server implemented in the node.js programming language. It creates a server on the device and WAITS for proxied commands from the main Appium server. The test scripts are written by the tester and run on the device or emulator. Appium creates and manages many webdriver sessions for various platforms such as Android and iOS.

Test scripts produced by the tester are sent to the Appium server as REQUESTS, which are then executed on the emulator or device. Each vendor has its own technique and methodology for EXECUTING test cases on the device, such as IOS or Android. As a result, the test case RUNS after the Appium server receives commands. To transmit command requests to the Appium server, Appium uses JSON (Javascript Object Notation) wire protocol. Here, JSON is USED to transmit data between the server and the client.

APPIUM offers an "Inspector" to record and playback, similar to Selenium IDE's record and playback tool. It inspects the Document Object Model to record and play native application BEHAVIOUR and PROVIDES test scripts in any preferred language. You can use the Inspector in Appium Desktop to look up or locate elements of an application. 

To locate an element, the Appium inspector provides four options:

• To find elements by id
• To find elements by class name
• To find elements by accessibility id
• To find elements by xpath. 

Appium Inspector does not support Windows and instead USES the UIAutomator viewer as an option.

FOLLOWING prerequisites must be installed so as to successfully RUN tests on an android application in Appium locally :

• JAVA Development KIT (JDK).
• Android Studio.
• Android SDK Tools.
• Eclipse IDE.
• Appium Desktop Client.
• TestNG.
• Selenium Server JAR.
• Webdriver Language Binding Library.

Following are the general responsibilities of a mobile APPLICATION testing framework:

• Choosing a format for expressing expectations
• Developing a means to connect to or control the test application
• Performing the tests and reporting the results

The general STRUCTURE of a mobile application testing framework consists of the following segments :

• Application Package: This refers to the TARGET application which needs to be run and tested.
• INSTRUMENTATION TestRunner: A test case runner that executes test cases against the target application. It includes an SDK tool for creating tests as well as an API tool, such as MonkeyRunner, that gives APIs for designing a program that controls an Android device.
• Test Package: Two classes, Test case classes, and Mock objects are included in the Test Package. The mock object contains mock data that will be USED as sample input for test cases, while the test case classes contain test methods to run on the target application.

In the above figure, we can see that a mobile application testing framework consists of three segments: Application package, InstrumentationTestRunner, and Test package. The test package consists of mock objects, test case classes, and Instrumentation and  JUnit classes.

Following are the advantages of using Appium on Sauce Labs rather than using Appium locally:

• It SAVES us the TIME that it takes to set up the Appium server locally.
• We do not need to install the mobile emulators and simulators OFFLINE in our SYSTEM. We can directly use it on Sauce Labs (an American cloud-hosted web and mobile application automated testing platform company based in San Francisco, California).
• It lets us scale our application instantly.
• We do not need to make any modifications to the source code of our application as is the case while using Appium locally.

There are many scenarios that can be tested when it comes to testing, especially for web applications, depending on the feature coverage you want to assure. Appium comes in helpful when it comes to testing scenarios that users will encounter when using your app.

Appium, on the other hand, becomes a restriction if you need to TEST more than UX SIMPLE interactions. Consider features such as KEYBOARDING. When SOPHISTICATED touch/keyboard mixed circumstances are involved, the likelihood of a false failure is significant. Exchanging data is another minor pain with Appium. You'll need to use various strategies when your test needs to exchange data with your app. So KEEP in mind that sending and receiving information isn't always simple. It's not Appium's fault; the WebDriver specification was created to automate processes, not data exchange.

No, we do not need a server machine to run TESTS on Appium. Appium encourages a two-tier architecture, in which a test machine CONNECTS to a test server that runs Appium, automating the entire process. This setting is optional; you can run Appium on the same system as your tests. Instead of connecting to a remote host, your test will use the LOOPBACK ADDRESS to connect to Appium.

Following are some of the important mobile application testings:

• Usability Testing: Usability testing is one of the sorts of web application testing that is perfect for assessing how the application makes it easier for users to achieve their goals. During this test, participants are given particular, realistic circumstances to use the application in. On the basis of gathering direct input from the end-user, usability testing is also reliable.
  As a result, the testing procedure is free of prejudice while simultaneously guaranteeing that highlighted areas improve. Usability testing also ensures that the design is intuitive and prioritises usability and customer experience.
• Performance Testing: Performance testing is a critical subset of mobile application testing that examines an application's performance, stability, and responsiveness under various workload situations. A performance test's main goal is to ensure that an application is completely aligned with the performance objectives. 
  Additionally, it addresses performance constraints prior to launching an application. Bottlenecks are processes inside a system's overall functions that cause the system's overall performance to slow or stall. Load testing, volume testing, soak testing, spike testing, and stress testing are all popular forms of performance assessments.
• Security Testing: In today's world, security is a major worry for practically every mobile application developer. According to reports, 80% of users are more likely to delete an application because of security concerns. As a result, it is critical to concentrate on mobile application security testing.
  Users' personal information is REQUIRED by certain programs, such as travel applications, for various transactions. If your application requires something similar, it's critical that you provide assurances about the application's confidentiality, integrity, and authenticity. You should have strong tests run on your application that assure that no one can break into someone else's account by unfair means.
• Interruption Testing: Interruption testing is important for determining how an application behaves when it is interrupted before returning to its FORMER state. Incoming phone calls or SMS, alarms, push notifications from mobile applications, battery low or full, network connection loss and recovery, and plugged in or out while charging are all examples of interruptions. In the event of an interruption, an application should normally run in the background and return to its prior state.
• Manual Testing: Manual testing is a tried and true method for thoroughly traversing the complexity of mobile application testing. Manual testing ensures that the finished product performs optimally in accordance with the PLANNED expectations. It's especially useful in situations where the use case isn't immediately evident. Professional QA testers could work in short bursts to assess an application and ensure that it produces accurate results.
• COMPATIBILITY Testing: Compatibility testing is one of the most important types of mobile application testing. It's a form of non-functional testing that ensures a mobile application's functionality across a variety of operating systems, applications, devices, internal hardware specs, and network conditions. Compatibility testing determines whether a mobile application is compatible with various operating systems and versions.
  It also tests a mobile application's compatibility with various devices, browsers, networks, and other characteristics. Backward compatibility testing and forward compatibility testing are the two types of compatibility testing.
• Localisation Testing: Localization testing is a must for mobile applications that are targeted at a certain geographic location. It's crucial to test the mobile application's responsiveness to the region's distinct language and cultural aspects. Local currency, use of SUITABLE time zone date and time formats, numerous local legislation needs, and the text and user interface are only a few of the important areas that localization testing evaluates.
• Functional Testing: Functional mobile application testing ensures that the application's functionalities meet the specified requirements. This form of testing focuses mostly on the mobile application's main goal and flow. Functionality testing determines if an application can properly launch and install. It also tests the simplicity of sign-up and login, as well as the presentation of push notifications and the proper operation of text boxes and buttons.
• Installation Testing: Installation testing, also known as implementation testing, is a good way to ensure that a mobile application is installed and removed correctly. Furthermore, installation testing is necessary to ensure that updates are seamless and error-free. Installation testing also examines what happens if users fail to update a mobile application.
• Automated Testing: Certain mobile application quality assessments are overly complicated and time-consuming. In such instances, Mobile application Test Automation Services come into play, providing optimally prepared and effectively conducted automated testing as well as manual testing, which can aid in assuring quality while also allowing for the speedier release of superior goods. As a result, automated testing is a solid source of time and cost savings when it comes to mobile application testing. There are various tools to perform automated testing. Appium is one of them.

FOLLOWING are the different TYPES of mobile applications:

• Native Applications: A native application is a program written in a specific programming language (such as Objective C for iOS or Java for Android) and INSTALLED directly on the device, allowing it to take full advantage of all of the device's characteristics. Native applications can work offline and utilise the device's notification system. App stores (such as Google Play or Apple's App Store) are used to install native applications. Native mobile applications have a high level of performance and dependability. Temple Run, Candy Crush, and other native apps are examples.
• Web Applications: Web applications are mobile web portals that have been specifically created, adapted, and hosted for mobile devices. They are accessed using a URL on the mobile device's web browser. When HTML5 was released, people learned that they could have native-like functionality in the browser, and web applications became extremely popular. Device capability is not available in mobile web applications. Google.com, m.snapdeal.com, m.yahoo.com, and more websites are examples of web applications.
• Hybrid Applications: Web applications embedded in native applications that operate on the device and are created using web technologies are known as hybrid applications (HTML5, CSS, and JavaScript). Hybrid applications run inside a native container and render HTML and handle JavaScript locally using the device's browser engine (not the browser). A web-to-native abstraction LAYER gives you access to the device features like the accelerometer, camera, and local storage that aren't available in mobile web applications. A hybrid application is not limited to a single PLATFORM or mobile device. As a result, once constructed, it can run on any device. Flipkart, Facebook, Twitter, and other hybrid applications are examples.

• Case when we should use a Simulator: Simulators are typically USED in software TESTING situations where the goal is to ensure that the application functions as intended when interacting with external applications or environments.
  For example, you could wish to SEE if an application can communicate data to another application. Because the actual HARDWARE configuration is unlikely to have much of an impact on data transfers for your program, a simulated environment will usually suffice. Simulated testing environments are also useful for ensuring that an application's interface shows properly across a range of screen resolutions.
• Case when we should use an Emulator: When you need to test how software interacts with underlying hardware or a combination of hardware and software, emulators come in handy.
  For example, if we want to discover if a firmware update will cause issues with our software or not, we can FIND out with the help of an emulator. Alternatively, we could want to know how our program performs when run on multiple CPUs or with varying memory allocations. Emulators come in handy in these situations as well.

Simulator: A simulator is used to simulate an environment with all of the software variables and configurations that will be present in the actual production environment of an application. Simulators do not try to replicate the actual hardware that will run the application in production. Simulators can be written in high-level programming languages because they merely construct software ENVIRONMENTS. For example, a car RACING game application can be thought of as a simulator as it simulates a real car race.

Emulator: An emulator does try to replicate all of the hardware and software aspects of a real-world environment. In most cases, you'll NEED to develop an emulator in assembly language to accomplish this. Emulators might thus be thought of as occupying a midway ground between simulators and real-world gadgets. For example, a car simulator racing game can be thought of as an emulator. It provides the hardware aspects of car racing as well with the help of emulators.

• Emulators replicate both hardware and software features, WHEREAS simulators solely simulate environment features that may be adjusted or created using the software. Emulators aren't a replacement for real-device testing since they don't always do a good job of simulating the hardware and software of a production system. They simply allow you to create an environment that is more SIMILAR to that of a real device.
• Emulators are somewhat slower as compared to simulators as emulators need to sense the movement of hardware devices, convert it into a digital signal, and then process them.

Following are the advantages of Appium:-

• Appium is an open-source application, implying that it can be downloaded for free and it is simple to set up.
• It can be used to run automated tests on hybrid, native as well as web applications.
• To make Appium compatible with automation, you don't need to integrate any new agents in your application, unlike other TESTING solutions. It tests on the very application that will be uploaded to the APP Store.
• Appium now has a new feature. Along with mobile application testing, it now supports desktop application testing for Windows.
• Appium is a cross-platform, open-source mobile testing solution that allows us to conduct cross-platform testing. As a result, you'll be able to test across a variety of platforms (single API for both Android and IOS platforms).

Following are the disadvantages of Appium:-

• There is no support for generating detailed reports of the tests executed.
• The tests are a LITTLE slow because they rely on the remote web driver.
• The fact that Appium uses UIAutomator for Android, which only supports Android SDK, API 16, or higher, is not a limitation, but rather an overhead. Appium, on the other HAND, does not natively support earlier APIs. To support older APIs, it makes use of an open-source library called Selendroid.
• On a Mac OS device, only one iOS Script can run at a time, which implies only one test can be run at a time. We will need the same number of Mac machines if we wish to run our tests on numerous iOS devices at the same time. Organizing many Mac machines, on the other hand, would be costly.

Following are the features of Appium:-

• Appium does not necessitate the USE of an APPLICATION's source code or a LIBRARY.
• Appium has a vibrant and engaged community of developers and so help is easily AVAILABLE from the community.
• Appium supports multi-platform testing, which MEANS it can execute the same test cases on several platforms like iOS mobile, Android mobile, and Windows desktop applications.
• Appium allows test scripts to run in parallel with other test scripts.
• A minor modification in Appium does not necessitate reinstalling the application.
• Appium supports a wide range of languages that use the Selenium client library, including C#, Python, Java, Ruby, PHP, JavaScript with node.js, and many others.