[Guest Blog by Uzi Eilon, CTO, Perfecto]
The “shift left” trend is actually happening, developers as part of the DevOps pipeline need to test more and add more automation testing in order to release faster.
In addition, those tests are almost the last barrier before production, because the traditional testing is going away.
In such case, the standard unit tests are not good enough, and the E2E tests are complicated and require a longer time of setup and prepare.
This is the reason both Google and Mozilla released new JS headless browsers to help their developers to execute automation tests.
The same happened in the mobile area where Apple and Google released the XCUItest and Espresso.
Headless browsers provide the following capabilities in order for the developers to use it:
- Same language , same IDE , same working environment:
Most of the web develops work with JS so these browsers are JS platform , to add new test you should open new class and write standard JS code. - FAST Feedback & Execution
These tests need to be executed fast (sometime every commit) , these browser reduce the UI and rendering “noise” connect to the element directly and run very fase. - Easy to setup
Developers time is expensive, and developers will not add complicated processes for test , the setup of the tools is a simple npm installation. - Access to all the DevTools capabilities
Developers need more details , these tools give access to all the DevTools data includes accessibility, network, log , security and more.
Smart tests can be very powerful and cover not only the functionally but also the efficiency
In order to understand more I played with Puppeteer and I’m happy share my thoughts with you.
Installation
Very simple
npm i –save puppeteer
Documentation
Not a lot of examples or discussions about specific issues but I did find the API documentation that contains everything I was looking for.
Objects identification
Intuitive – Same way I connected to my object via any JS .
Example:
- by id : page.type(‘#firstName’,‘Uzi’);·
- by class page.type(‘.class,‘Uzi’);
Sync and waiting for elements
In this case, I have to admit I struggled with the standard wait for navigation command, it was not stable:
await page.waitForNavigation({waitUntil:‘load’})
at the end I used the following :
await page.waitForSelector(‘#firstName’,{visible:true}).then(()=>
{ // do the actions per page
page.screenshot({path: ‘then.png’,fullPage: false})
});
UI
As part of my test I tried to verify the screen by taking a screenshot, I liked the way I could change the browser UI capabilities and configure my page:
const fullScreen = {
deviceScaleFactor: 1,
hasTouch: false,
height: 2400 ,
isLandscape: false,
isMobile: false,
width: 1800,
fullPage: true
};
page.setViewport(fullScreen)
Other devOpts options:
it is very easy to use, for example I would like to see all my links in a frame
for (let child of frame.childFrames())
{
dumpFrameTree(child, indent + ‘ ‘);
}
Summary:
Using the headless browser like Puppeteer was very easy and intuitive, it felt natural to add it as part of my testing code.
In addition, setting up the headless browser environment and executing was very simple and fast.
On the less convenient point, what I found was that to get the results directly into the CI, one should add more scripting code or use other executions methods.
Lastly, this method still ramps up, hence has some small bugs in few features and also lacks documentation and more samples, however, for an early testing tool for white-box/unit testing, it is very promising and well-positioned to complement tools such as Selenium. AS a matter of fact, what I also saw, is that other browser vendors are taking the same approach and investing in headless browsers – Mozilla, Microsoft.
P.S: If you want to learn more about the growing technologies and trends in the market, I encourage you to follow My podcast with Uzi Eilon called Testium (Episode 6 is fully dedicated to this subject)
Continuous Testing and DevOps Blog 