In this article, I will show you how to create custom commands in Cypress. Cypress Custom Commands
What are Custom Commands in Cypress?
Cypress custom commands are commands that are described by the user and used to create repeating steps in an automation test. By using custom commands you only need to define the command once and only use one line to call those commands.
Syntax
The syntax for the custom commands in Cypress is as follows:
function-name is the name of the command you are about to invoke.
func is a function that accepts the arguments passed to the command.
opts is an optional parameter used to describe the implicit characteristics of a custom command.
How to implement custom commands in Cypress?
For this article’s simulation, I will use a dummy test automation website from zero.webappsecurity.com.
This site is not a real banking site and any similarities to third-party products and/or Web sites are purely coincidental. To access the website, you can click the link below.
Suppose our application has a scenario where we need to log in to a website before we can do the real test within the user page. In doing so, we need to clear cookies and local storage. Then insert the username and password into the user_login and user_password fields. After that click remember_me and Sign in button
So, instead of invoking the get() and click() commands before every test scenario, we can add a new custom command which will execute the login procedure every time it is called. So, to achieve the result, we can declare a new custom command as follows. The script below is the implementation of a custom command in commands.js
So, it will call the login command and pass the parameter ‘username’ and ‘password’. Both parameters will be used as input values for the user_login and user_password fields. This way, we can execute login only using one line rather than typing every step in the login procedure.
Run the Cypress, and you will get the result as follows:
Custom command result You can see in the log that the commands in the custom command are being executed.
Software testing is an activity to make sure that the software product meets the expected criteria and to make sure that the software has a minimal defects. Software testing aims to minimize bugs, find a missing requirement, or identify that the software meets acceptance criteria. What activities can be done manually and/or automatically?
Why we need software testing?
We need software testing because bugs in production are either very expensive or dangerous. We can lost our potential customer, sell opportunity, or even cause a disaster. If we can catch the bug earlier than we can fix it sooner before the delivery of the product. Thus the cost will be cheaper.
Software Testing Life Cycle (STLC)
What is STLC?
Software Testing Life Cycle (STLC) is a sequence of systematic and planned activities which are executed during software testing activities. STLC is an important process because it ensure the quality of the software. Different with SDLC, that covers the whole software development process, STLC only covers testing activity.
Software Testing Life Cycle (STLC) has six major steps, which are:
Requirement Analysis
Test Planning
Test Case Development
Test Environment Setup
Test Execution
Test Closure
Each of those step has an entry criteria, activity, deliverable and exit criteria related to it.
Entry criteria are initial conditions that must be met before the test process can be run
Exit criteria are items that must be completed during the testing process so that testing can be considered complete.
Activity is activities that are carried out during the testing process.
Deliverable is the result that can delivered after the test is finished.
To read more about STLC please follow the link bellow.
Acceptance testing: Make sure that all services is working as intended.
Integration testing: Make sure that all components are working together.
Unit testing: Checking that function is working in the unit level.
Functional testing: Validating the functionality of the services by simulating user behavior or business process. Can be done using black box testing.
Performance testing: Checking how the software performs under a ramping up workloads. Can be done using Load testing.
Regression testing: Validating that the old menus or services still working after new features are introduced.
Stress testing: Testing how much request can be processed before the system is breaking.
Usability testing: Validating how well a customer can use a system or web application to complete a task.
White box VS Black box
White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) verifies the internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing, an internal perspective of the system (the source code), as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. While white-box testing can be applied at the unit, integration, and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.
Black-box testing (also known as functional testing) treats the software as a “black box,” examining functionality without any knowledge of internal implementation, without seeing the source code. The testers are only aware of what the software is supposed to do, not how it does it. Black-box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing, and specification-based testing.
In this article, I will show you how to create a constant that contains an HTML path in Cypress. Sometimes, when creating tests for the front end, we need to access elements under the long HTML path. It will be troublesome if we need to assert elements under the same long path. The workaround I suggest is to save the path into a constant then we call the constant to assert the element.
To achieve the result, we can implement the script below:
describe('Login with Cypress.$ Function', ()=>{ before(function() { cy.visit('http://zero.webappsecurity.com/login.html'); })
That script will save the user_login, user_password, user_remember_me, and Sign in button to a constant, then we can call the constant to create an assertion.
Cypress Fixture In this article, I will show you how to separate test data from the test script. While designing a Test Automation Framework, it is important to segregate the test scripts from the test data. With help of fixtures, Cypress is capable to do that.
What is a fixture in Cypress?
Cypress fixtures are used to store test data for automation, and the fixtures folder is placed inside the Cypress project. The fixtures folder contains JSON files, which contain test data that can be read by multiple tests. We store this data in a key-value format, which allows us to access it in our test scripts.
How to use Fixtures in Cypress Tests?
For this article’s simulation, I will use a dummy test automation website from zero.webappsecurity.com.
This site is published by Micro Focus Fortify for the sole purpose of demonstrating the functionality and effectiveness of Micro Focus Fortify’s WebInspect products in detecting and reporting Web application vulnerabilities.
This site is not a real banking site and any similarities to third-party products and/or Web sites are purely coincidental. To access the website, you can click the link below.
Fixtures folder in cypress hierarchy Within the folder, create a file in JSON or other formats, and the data is maintained in “key:value” pairs. For this login simulation, I will create JSON and name it user.json. We can specify our test data with the following values:
As we can see, I usecy.fixture to call the data from the fixture file “user.json” and use the values obtained to fill in the username and password fields. Save the above test files as and run the test as per the steps mentioned in the article “Cypress Test: Create your first End-to-End Testing”.
Loop a dynamic test data
In this section, I will show you, how the fixture file is consist of an array and want to use all the data as test data. I will create JSON and name it userDynamic.json with the following values:
Save the above test files as and run the test. It will iterate array data from dataDynamic.json and use the values obtained to fill in the username and password fields.
Conclusion
The fixture provides segregation between test data and test script and allows the uses external data to be used in the test. It also allows the test to use multiple input data.
The viewport is used to control the size and orientation of the screen for your application. Emulate Different Devices Using Viewport This is an example of how to use a viewport to emulate different device’s screens:
As we can see together, I use cy.viewport to declare the size of the screen. In addition to using the size of the resolution, the viewport can also be defined using the type of device.
This article is a continuation of the QA technique series. To read previous articles in the same series, you are welcome to follow the link below.
QA Techniques: Black Box Testing
If in the previous article I wrote about black box testing, in this article I will write about white box testing,
White box testing
What is White Box Testing?
White box testing is a software testing method that takes advantage of an internal view of the software code.
It is called a ‘white box’ because you can see inside an application’s source code and observe the way it is put together. With white box testing, test data enters the system via parameters, variables, and stored procedures and exits through return codes and stored procedures. This allows you to follow logic paths through the system as well as error-handling paths.
White Box Testing Techniques
White box testing is a technique that allows you to test your code at the source level. This means that you can test every line of code in a module or class. It also means that you can test the relationships between different modules and classes.
White box testing techniques include statement coverage, branch coverage, condition coverage, basis path testing, graph notation, Cyclomatic Complexity, and loop testing.
Statement coverage
Statement Coverage is the most basic and fundamental test coverage technique.
It focuses on testing all individual statements in a program at least once. Thus every node in the flowchart is tested.
Although this may seem trivial, it helps to achieve 100% statement test coverage. Because of this, it’s often considered a minimum requirement for any level of testing.
Branch Coverage
Branch Coverage ensures that the test for every possible path (if-else and loops) has been executed at least once by running all combinations of boolean expressions.
The idea behind branch coverage is that each decision condition should be tested with both true and false values; covering these branches is an important step toward achieving full branch coverage.
Branch coverage may also be referred to as condition-decision coverage or decision-branch coverage.
Condition Coverage
Condition Coverage ensures that every conditional statement has been evaluated at least once by running through all possible combinations of boolean expressions.
For example, there are conditions; X<0 and Y>0. Then we’ll have 4 possible conditions; TRUE and TRUE, TRUE and FALSE, FALSE and TRUE, and FALSE and FALSE.
Basis Path Testing
Basis path testing is a method that allows test case designers to make measurements of the logical complexity of the procedural design and use these measurements as a guide for defining the basis set of execution paths.
Test cases created to test the basis set are guaranteed to execute every statement in the program at least once during testing
Flow graph notation
This technique uses a directed graph to identify all possible paths and then maps those paths to create tests for them.
The graph is consist of nodes, decision nodes, junction nodes, and edges, and each node represents a sequence or decision point.
Cyclomatic Complexity
Cyclomatic complexity is used to determine the number of paths that need to be searched.
Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. The value calculated for cyclomatic complexity determines the number of independent paths in the base set of a program and provides the minimum number of tests that must be performed to ensure that all statements have been executed at least once.
Loop testing
This test is mandatory to test various loops in the program, such as do-while, for, and while. In this test, you can also check the condition of the loop, whether it is running correctly or not.
Advantages of White Box Testing
White box testing is very thorough so it can increase accuracy in implementing software.
Makes it easy to find errors or bugs in software that were not previously seen.
Can be executed early so that it can detect bugs early.
Facilitates testing because it is carried out thoroughly so as to minimize the possibility of errors in the code.
Disadvantages of White Box Testing
Quite complex.
Hard to maintain, because if there is any changes in the code, we need to rewrite the testcase.
Consumes a lot of resources because White-box testing is a fairly expensive test.
Expensive.
Conclusion
So, we already talk about White Box Testing, as a part of the Testing Technique series. We already talk about the definition of white-box testing, the technique of white-box testing, also the advantages and disadvantages of white-box testing.
