Michael Bryan

Michael Bryan


Testing your web extension with integration tests

It is often described how to do unit tests for web extensions but hardly said how to do integration tests. Here, I am presenting the method to embed a Jasmine HTML page inside a page of your web extension.

The need of testing

Testing is a core strategy in software development. It helps the developer to keep knowledge about the app and guarantee the code and the features keep their engagement.

When I started the extension Sync Tab Groups, I first tested it manually. While it was working for the first weeks, I quickly felt I was losing time and getting less confident about each release. The day I released a critical bug was the signal.

Although pretty easy for testing React or Node, the web extension ecosystem is younger and less rich. The best approach, I found so far, is to mock the tests with sinon and run them in a DOM emulation (Jest for example).

I decline this solution for 2 reasons:

1. The library is not complete for Chrome and definitely lacks some Firefox specific features

2. Mocked tests are useful and fast but not as safe as the integration tests

Finally, by looking at the Jasmine library, I discovered I could embed my tests in an HTML page.

How to embed tests in a web extension page

In a web extension, the extension API is available on different parts

1. In your background task

2. On your extension pages

I started my small test library in the background task. I stopped immediately. Not only coding a library is tough but lacking a nice interface made it hard to iterate.

I quickly switched to the extension pages with the support of the Jasmine library. I downloaded all the HTML, JS and CSS files and added all my tests in “describe” and “it” blocks in the imported JS files.

In a later version, I will use Webpack to create the test page. On one side, I will build a single JavaScript file with all the tests inside. And on the other side, I will fetch the Jasmine assets directly from the “node_modules/” folder. I am going to write another article on how to build a web extension with Webpack soon.

How to design your tests

While the concept is simple, I iterated regularly in order to improve the testing experience.

Bind the web page to the background script

By default, the web extension doesn’t access the full web extension API. A solution is to require the background window where the core of the extension is running.

Be careful, the function is asynchronous, thus, you should wait before executing any tests. When I added the Chrome support on Sync Tab Groups, at first I forgot to wait. As a consequence, the tests were randomly failing.

const waitInit = async() => {
  const Background = await browser.runtime.getBackgroundPage();
  // Available everywhere
  window.Background = Background

// Store the original start function from Jasmine
const currentWindowOnload = window.onload;

// Overload the event to first get the background
window.onload = async function() {
await waitInit;

if (currentWindowOnload) {

Note: all the code available in the article is coming from the Sync Tab Groups repository.

Mock the timers

The window functions (“setTimeout”…) in the page are not the same than the ones in your background script. If you want to mock the time, you should modify the ones in the background object with the Jasmine mocked functions.

const TIME_OBJECTS = [

const savedTime = {};
function installFakeTime() {
if (!Object.keys(savedTime).length) {
// Call Jasmine to mock the timer functions in the current window object
savedTime = {};
// Replace the background objects with the mocked versions
savedTime[time] = window.Background[time];
window.Background[time] = window[time];

function uninstallFakeTime() {
if (Object.keys(savedTime).length) {
Object.assign(window.Background, savedTime);
savedTime = {};

Improve the test experience

One of the first pain I got was caused by the tests starting automatically each time the page was loaded. A solution is to overwrite the filter with a string that won’t match any test title. The filter is overwritten dynamically in order to not have strange URLs.

My second pain was to list all the tests. By using the previous solution that stops the test execution, you set the enable parameter to false. If you set to empty the URL spec parameter, then all the tests are listed in light gray. If the spec parameter is not empty, the page will only list the test titles that matched it.

const queryString = new jasmine.QueryString({
getWindowLocation: function() {
return window.location;

const specFilter = new jasmine.HtmlSpecFilter({
filterString: function() {
if (getUrlParameterValueByName(“enable”) !== ‘true’) {
// A fake string that matches no test
return “@@@@@@@”;
} else {
// Normal behavior: “spec” value is a regex to filter the test names
return queryString.getParam(“spec”)

const env = jasmine.getEnv();
env.specFilter = function(spec) {
return specFilter.matches(spec.getFullName());

This small interface on top of the Jasmine page helps to control the tests. By clicking on the “Enable” button the tests are executed on the next page refresh. Whereas “See all tests” button disables the test execution (the enable parameter to false) and resets the filter (the spec parameter to the empty value).

// Enable button: execute or not the tests on page load
// If not, ALL the tests are displayed in light gray
// Use a trick that jasmine won’t execute nothing if the URL spec parameter is empty
const enableButton = document.createElement(“button”);
enableButton.innerText = Utils.getParameterByName(“enable”) === ‘true’
? “Disable”
: “Enable”;
enableButton.addEventListener(“click”, () => {
if (Utils.getParameterByName(“enable”) === ‘true’) {
// Set (add) a parameter “key” in the URL with the value
// @example (“k”, “val”) => http://www.site.fr/?k=val
// @source https://stackoverflow.com/a/487049/7186064
insertParam(“enable”, “false”);
} else {
insertParam(“enable”, “true”);

// Add the buttons when the page is loaded
document.addEventListener(“DOMContentLoaded”, () => {
// I added this code in the body tag of the HTML page
// <h3>Test page</h3>
// <button><a href=“?spec=”>See all tests</a></button>
document.body.insertBefore(enableButton, document.querySelector(“button”));
const div = document.createElement(‘div’);
div.innerText = Filter: "${Utils.getParameterByName("spec")}";
document.body.insertBefore(div, enableButton);

Automatically open the page

Extension pages have often strange and unpredictable URLs. On top of that, they close each time you reload your extension. A nice solution is to add a system to automatically open pages when the extension starts (in the development mode of course). The web extension API provides a function to open a page from a local path without knowing the extension id.

const DEV_TABS = [
// tests pages
// options
// test page with a specific test targeted in spec

// To execute when the extension is detected to be in developement mode
function onDevelopmentInstall() {
// Open the tabs
active: false,
url: browser.extension.getURL(url),

// Add extra code you want to be done in Development

It is easy to detect when the extension is under development thanks to the “temporary” property in Firefox. For Chrome, an alternative method based on the values of some fields is necessary as the “temporary” field is missing. Although it works, it shows a reality, Firefox works harder to make the extension developer life easier than with Chrome.

browser.runtime.onInstalled.addListener((details) => {
if (details.reason === “install”) {
// Extension has been installed (first time only)
} else if (
(Utils.isFirefox() && details.temporary)
|| (Utils.isChrome() && details.reason === “update”
&& (browser.runtime.getManifest()).version === details.previousVersion
) {
// Extension has been reloaded in development
} else if (details.reason === “update”
&& (browser.runtime.getManifest()).version !== details.previousVersion) {
// Extension has been updated to a new version

Use mocked tabs

When I first did my tests, I was using a random pool of real URLs for the tabs in my groups. When the number of the tests increased significantly, the test suite was taking longer and my computer was over computing.

Actually, loading a tab in your browser is an expensive task because of the graphical resources and the scripts (tracking, page interactions…). On top of that, if they open by ten without letting time for your computer to finish, the navigation is getting horrible.

A new solution using a custom (empty) web extension page solves the issue. It has 2 advantages:

  1. The tab is lighter to load (no images, no JavaScript)
  2. It is local to the extension, thus there is no network time

For some tests you want to differentiate the pages to know if a specific page does something. As the extension can’t change the HTML content at opening, you could use an URL parameter set with a random number. Be careful, it might have number collision leading to random failing tests. A better solution would be to store the number to avoid using a number more than one.

Since the mock tabs don’t use the network, it allows to develop the extension without an internet connection. A great improvement to code even on the train!


  • Return an url to a web extension page with a minimal body
  • The URL is personalized with a number set to the parameter test
    function getFakeUrl(random=String(getRandom(0,999999999))) {
    return browser.extension.getURL(“/tests/test-page/template/template.html”)
    + “?test=” + random;


  • Return a light local tab in the web extension
  • with a personalized URL to recognize them
    function getFakeTab() {
    const random = String(getRandom(0,999999999));
    // Return a minimalist tab
    return createTab({
    url: getFakeUrl(random),
    title: random,
    favIconUrl: “”,

Create your toolbox to control the browser

As the tests are running inside the UI browser, it might get difficult to follow the current test execution for debugging. For example, you might wish to look at the test states to know if some tests have already failed or how close the tests are from the end.

Another problem exists if you test features that use more than one browser window. You want to visualize the test running in all the browser windows to check everything is going well while you are writing it.

It is easy to use some web extension functions to resize the browser windows to fit better in the screen. You could change manually the setting to fit a single or double screen configuration.

async function splitOnHalfScreen(windowId) {
try {
return browser.windows.update(windowId, {
left: TestUtils.DOUBLE_MONITORS?window.screen.width:0,
top: 3,
width: Math.round(window.screen.width/2),
height: window.screen.height,
state: “normal”,
} catch (e) {
window.Background.LogManager.error(e, {args: arguments}, {logs: null});

And some insoluble problems…

Whereas it is easy now to test a web extension with integration tests, some behaviors are still problematic

  • Some tests are failing in the Mac full screen mode (no idea why)
  • While the tests are running, you might not be able to use your computer as changing the focus could make the tests failing

Improvement ideas

I just want to share with you some improvements I never tried because I run out of time.

Headless Browser

A pain that still remain is that during the tests my computer is unavailable. I read some things about seleniumpuppeter and Firefox Headless mode. However, I never tried! Also, the Firefox “web-ext” tool could even be a solution to do continuous integration.

Remote testing

I studied another solution I was never able to implement. Mocha is a server for sharing your tests in the browser.

It works by opening a local server that gets connected by the browser in a tab. By continuously exchanging, the Mocha server is sending the tests are waiting for the responses.

The reason I gave up this solution, was due to the tab page was targeting the localhost and thus wasn’t an extension page. This involves you got access only to a limited part of the API (not to the background script).


By embedding the Jasmine test page into your web extension, you could use the agility of a test framework with the full power of the web extension API.

In my project Sync Tab Groups, I was able to ensure all my features were truly working on the new releases. Independently of knowing if the web extension in the browser was changing. I used to release many times a week when I was only working on this project without regression.

By the way, I am still looking for contributors to help me developing Sync Tab Groups. :)

Originally published by Eric Masseran at https://medium.com/@Morikko/testing-your-web-extension-with-integration-tests-f875f1f52ff9

Follow great articles on Twitter

Learn More

☞ The Web Developer Bootcamp

☞ Angular 7 (formerly Angular 2) - The Complete Guide

☞ Learn and Understand AngularJS

☞ The Complete JavaScript Course: Build a Real-World Project

☞ Become a JavaScript developer - Learn (React, Node,Angular)

☞ Build Responsive Real World Websites with HTML5 and CSS3

☞ Web Design for Beginners: Real World Coding in HTML & CSS

☞ React 16 - The Complete Guide (incl. React Router 4 & Redux)

☞ The Complete Node.js Developer Course (2nd Edition)

☞ MERN Stack Front To Back: Full Stack React, Redux & Node.js

#javascript #web-development

What is GEEK

Buddha Community

Testing your web extension with integration tests

Software Testing 101: Regression Tests, Unit Tests, Integration Tests

Automation and segregation can help you build better software
If you write automated tests and deliver them to the customer, he can make sure the software is working properly. And, at the end of the day, he paid for it.

Ok. We can segregate or separate the tests according to some criteria. For example, “white box” tests are used to measure the internal quality of the software, in addition to the expected results. They are very useful to know the percentage of lines of code executed, the cyclomatic complexity and several other software metrics. Unit tests are white box tests.

#testing #software testing #regression tests #unit tests #integration tests

Tamia  Walter

Tamia Walter


Testing Microservices Applications

The shift towards microservices and modular applications makes testing more important and more challenging at the same time. You have to make sure that the microservices running in containers perform well and as intended, but you can no longer rely on conventional testing strategies to get the job done.

This is where new testing approaches are needed. Testing your microservices applications require the right approach, a suitable set of tools, and immense attention to details. This article will guide you through the process of testing your microservices and talk about the challenges you will have to overcome along the way. Let’s get started, shall we?

A Brave New World

Traditionally, testing a monolith application meant configuring a test environment and setting up all of the application components in a way that matched the production environment. It took time to set up the testing environment, and there were a lot of complexities around the process.

Testing also requires the application to run in full. It is not possible to test monolith apps on a per-component basis, mainly because there is usually a base code that ties everything together, and the app is designed to run as a complete app to work properly.

Microservices running in containers offer one particular advantage: universal compatibility. You don’t have to match the testing environment with the deployment architecture exactly, and you can get away with testing individual components rather than the full app in some situations.

Of course, you will have to embrace the new cloud-native approach across the pipeline. Rather than creating critical dependencies between microservices, you need to treat each one as a semi-independent module.

The only monolith or centralized portion of the application is the database, but this too is an easy challenge to overcome. As long as you have a persistent database running on your test environment, you can perform tests at any time.

Keep in mind that there are additional things to focus on when testing microservices.

  • Microservices rely on network communications to talk to each other, so network reliability and requirements must be part of the testing.
  • Automation and infrastructure elements are now added as codes, and you have to make sure that they also run properly when microservices are pushed through the pipeline
  • While containerization is universal, you still have to pay attention to specific dependencies and create a testing strategy that allows for those dependencies to be included

Test containers are the method of choice for many developers. Unlike monolith apps, which lets you use stubs and mocks for testing, microservices need to be tested in test containers. Many CI/CD pipelines actually integrate production microservices as part of the testing process.

Contract Testing as an Approach

As mentioned before, there are many ways to test microservices effectively, but the one approach that developers now use reliably is contract testing. Loosely coupled microservices can be tested in an effective and efficient way using contract testing, mainly because this testing approach focuses on contracts; in other words, it focuses on how components or microservices communicate with each other.

Syntax and semantics construct how components communicate with each other. By defining syntax and semantics in a standardized way and testing microservices based on their ability to generate the right message formats and meet behavioral expectations, you can rest assured knowing that the microservices will behave as intended when deployed.

Ways to Test Microservices

It is easy to fall into the trap of making testing microservices complicated, but there are ways to avoid this problem. Testing microservices doesn’t have to be complicated at all when you have the right strategy in place.

There are several ways to test microservices too, including:

  • Unit testing: Which allows developers to test microservices in a granular way. It doesn’t limit testing to individual microservices, but rather allows developers to take a more granular approach such as testing individual features or runtimes.
  • Integration testing: Which handles the testing of microservices in an interactive way. Microservices still need to work with each other when they are deployed, and integration testing is a key process in making sure that they do.
  • End-to-end testing: Which⁠—as the name suggests⁠—tests microservices as a complete app. This type of testing enables the testing of features, UI, communications, and other components that construct the app.

What’s important to note is the fact that these testing approaches allow for asynchronous testing. After all, asynchronous development is what makes developing microservices very appealing in the first place. By allowing for asynchronous testing, you can also make sure that components or microservices can be updated independently to one another.

#blog #microservices #testing #caylent #contract testing #end-to-end testing #hoverfly #integration testing #microservices #microservices architecture #pact #testing #unit testing #vagrant #vcr

Ray  Patel

Ray Patel


Advance Web Penetration Testing Tool For Python

Features 🎭

Admin Panel Finder

Admin Scanner

Dork Generator

Advance Dork Finder

Extract Links

No Redirect

Hash Crack (Online-Database)

Hash Crack (Wordlist)

Whois Lookup

Tcp Port Scan

Geo IP Lookup

Reserve Analysts Search

Csrf Vernavility Checker


WordPress Username Finder

#testing #advance web penetration testing tool for python #python #advance web penetration #testing tool for python #web

Jamal  Lemke

Jamal Lemke


Ten Principles For Agile Testers

In the previous blog we saw that what exactly is Agile testing and in this blog we will see in introduction to Principles For Agile Testers.

What is an Agile tester?

  • So get into the principles for Agile testers we first need to know what is an Agile tester? A professional tester who is not scared of change has knowledge about technical and business aspects as well and understands the concept of using tests to document requirements to drive development is an Agile tester.
  • Now let’s see what are in ten principles for Agile testers:
  • Provide continuous feedback.
  • Deliver value to the customer.
  • Enable face-to-face communication.
  • Have courage.
  • Keep it simple.
  • Practice continuous improvement.
  • Respond to change.
  • Self-organize.
  • Focus on people.
  • Enjoy

Provide Continuous Feedback

  • Continuous feedback is the key to agile testing success. By providing feedback we can improve and not make the same mistakes again and again. The main aim is to learn from your mistakes. Testers should help product owners or customers visualize requirements for the stories. Their feedbacks helps in designing the test cases early in the software life cycle. As retrospectives are an important part of the Agile process, providing feedback in it is also helpful. It is one of the most important principles for Agile testers.

Deliver Value to the Customer

  • As a tester, it’s your responsibility to tell customers which really is an important function and which is not. The testers help them identify the main functionality instead of just some cool features. The main focus is to try and deliver critical functionality and enhance it later. Critical functionalities should be worked on first as after seeing them implemented, customers can see what enhancements they want. Testing should work on corner cases but should not forget about the happy path of the service. As we get involved in testing it is possible to get involved in corner cases so much that we miss the core functionality. So, we need to maintain a balance between them.

Enable Face-to-Face Communication

  • Good communication is the key to success. Agile’s success is totally dependent upon communication. Whether it is between customer and developer or between developers and the testers all communication is very important. Testers should look for unique ways to communicate. Teams may be working in geographically divided. But it should not hinder communications between the teams.
  • Testers should never get in the way of any direct customer-developer communication but should help to make sure that communication happens. If a tester finds out that the developer has some confusion regarding the requirements. It’s the responsibility of the tester to set up a meeting between the developer and the business.
  • The testers understand the story from the customer’s perspective and from the developers’ technical angle as well. The tester should be able to communicate both ways, that’s why it’s in testers’ best interest to be good at communicating, as they need to do it more than any other team member. Testers act as a bridge between customers and developers.

Have Courage

  • The testers should have the courage to speak their minds. They should not be intimidated by anyone. If they find any issue they should report it. If they see any gap in the business requirements they should discuss it.
  • The testers should be comfortable in asking customers for examples or developers for help. Asking for examples is the best way for getting the real-world use case of the services. In Agile anyone can perform any task. So, a developer can help a tester in testing some particular scenario. And a tester can help the developers in debugging an issue ass well.
  • Testers should not be scared to fail but should learn from their mistake. It’s natural to make some mistakes but we should always learn from them and improve ourselves.

#api testing #integration testing #quality assurance (qa) #testing #unit testing #agile #agile teams #agile transformation #agiledeveloper #automation #automation testing #testing skills

Unit Testing Is NOT The Same As Integration Testing

When Integration Testing Gets Tricky

Certain truly external systems may be difficult to integrate into tests. This is because they have side effects in the real world that cannot be undone: A financial transaction, an email send, physically moving a paint robot. Before you give up and sidestep them in your testing, look around for solutions.

Many external systems will have a documented way to use them in an integration test. Payment processors often have test credit card numbers, and test users with test email accounts can be set up for testing delivery. The closer integration tests are to real-world interactions the more likely they are to catch problems and provide real value.

#testing #unit testing test #integration testing