Posted on

E2E Testing with React, Jest, and the TestProject JavaScript OpenSDK

With a long list of end-to-end (e2e) test frameworks available to choose from, it’s hard to know which one you should be using. Cypress and Selenium are leading the market as the most widely used options, but there’s also Appium for mobile app testing, Puppeteer for automating tasks in Chrome, and Protractor for Angular and AngularJS applications, just to name a few.

Recently a newcomer has joined the pack: TestProject, a free, open-source test automation platform for e2e testing that helps simplify web, mobile, and API testing. The TestProject SDK has language support for Java, C#, Python, and, most recently, JavaScript.

Posted on

E2E Testing With Cypress on Jenkins With Parallel Pipeline Stages

In this tutorial for JavaScript end-to-end testing, you will learn about Cypress test runner for UI automation testing and how to use it with the Jenkins CI server. Cypress helps with frontend automation testing using a headless browser or just a regular browser. E2E tests often take a long time to run and for bigger projects, those types of tests can take dozens of minutes or even hours. To save developers time you want to load balancing Cypress tests across Jenkins parallel pipeline stages. Thanks to that, you can run your 1-hour test suite in a few minutes.

How to Speed Up Cypress Tests

Cypress is a Javascript End to End testing framework that has built-in parallelisation but in this article, we will cover Cypress parallel without dashboard service. You want to be able to run tests also when the external Cypress dashboard service API is down. It’s possible thanks to the Knapsack Pro client for Cypress with built-in Fallback Mode.

Posted on

Fast CI Build Time With Parallel Jobs on Semaphore CI for RSpec, Cypress, and Jest Tests

Semaphore CI 2.0 allows for configuring your CI build task with parallel jobs. This way, you can run simultaneously a few different commands that do not depend on each other. But we could also use parallel jobs to split your test suite across a few jobs and save time this way. I will show you how to speed up your CI build for your Ruby or JavaScript project (Rails/Node project).

With Semaphore CI 2.0, you don’t pay for a reserved amount of containers that can be run in parallel as in some other CI providers. Instead, they count the amount of work time spent on running containers. This creates an incentive to run more parallel jobs to execute our tests fast and still keep bill at a similar level as if we would just run all tests in single container waisting our own time.

Posted on

E2E Test — Use Probe Attribute As Element Locator

If you have experiences to create an E2E test project on a web application, you should be familiar with codes like this.

JavaScript
  




xxxxxxxxxx
1


 
1 
// Manipulate browser to enter text to an input box
2 
    const fooInput = await getElement('.fooInput');
3 
    fooInput.type("user.name@email.com");
4 

          

          

           

            

             5
            

           

           
    // Manipulate browser to click the submit button

          

          

           

            

             6
            

           

           
    const fooButton = await getElement('button[type=sybmit]');

          

          

           

            

             7
            

           

           
    fooButton.click();

          

          

           

            

             8
            

           

           

          

          

           

            

             9
            

           

           
    // Then verify what is happening after form submit

          

         

        

       

      

     

     

      

     

     

      

       

      

     

    

   

  

 





	


	





		

		
Posted on 
Beyond Whack-A-Bug: From Reactive to Proactive E2E Testing
	


			

			
							
		

	
	

		
Of all of the classic arcade games, Whack-A-Mole just might be the most frustrating. You can’t win the game of Whack-A-Mole. Every time you think you’ve hit the mole, the little scoundrel always finds a way to pop up again somewhere else, and you’re always one step behind. 


In the world of end-to-end testing, we can get stuck playing Whack-A-Bug when we reactively write tests to bugs that pop up in production in order to prevent them from appearing again. I like to call this practice Whack-A-Bug testing because it’s a common approach, yet can easily become an endless cycle in which testers are always one step behind. As leaders in our organizations, we must instead figure out how to be one step ahead, committing to developing more courageous, forward-thinking E2E testing strategies.
	


	





		

		
Posted on 
Calculating Java Code Coverage for Non-JVM e2e Tests Suite and More With JCov
	


			

			
							
		

	
	

		
1. What Is Dynamic Instrumentation Code Coverage and Why Do We Want It?


Java code coverage tools, like these embedded in IDEs or provided as CI environments plugins, are great, but they have one limitation — the tests you run have to also be written in Java or other JVM language. What if you have suites of tests in other, non-JVM languages and would like to know what is covered and what is not?


I've faced such an issue — we had a really big suite of e2e REST API tests written in Python and executed them against big Java application running on Tomcat. We wanted to track where these tests go in the code. But how to check it?