Sometimes we need a specific chrome version to test because of

• the minimal supporting version
• or customers’ feedback
• …

Sadly it’s not easy to find a real and safe chrome history version. As chromium said

Google does not offer old builds as they do not have up-to-date security fixes.

Some people also don’t know where to find the future versions. So I write this article to note how to find these resources.

Old chrome

Non-official resources

There’re some websites providing some old versions. But use it cautiously!

• https://www.slimjet.com/chrome/google-chrome-old-version.php
• https://filehippo.com/download_google-chrome/history/

Official chromium versions

According to the chromium document

Chromium is the web browser that Google Chrome is built on.

Normally you can reproduce the issues you met using the corresponding chromium version.

Chromium provides a way to download old builds. You can follow the steps listed in the document.

Another way is using chromium-history-page. It’s not an official page, but it’ll redirect you to the official builds download page.

Then you can install the specific version to test.

Future Chrome versions

It’s quite easy to download the future versions. In the homepage, you can find them and download them.

Basically, they’re beta, dev, and canary. beta version is the next version, and also the version that developers are searching for when they need a future version.

Because chrome is distributed gradually. Some people’s browsers will be affected first. Developers might receive defects coming from customers because the experimental changes make their websites unavailable. And they can not reproduce on their own computer.

In this case, we can download the beta version and sometimes need to turn on some feature flags to reproduce the defects and fix them.

You can also see the release date, progress, and changes in the roadmap.

Okay, now you know where to download the old and future Chrome versions!

Issue

Source

Reference

It’s very common that developers don’t have time to write tests, especially unit tests.

In real-world apps, unit tests take lots of time so many teams give it up. Since they have given up the foundation of the test suit(unit test), they will also give up other tests. emmm……

Actually, investing time in e2e(end-to-end) tests can be a cost-effective choice, especially for web apps. The least time can help you solve the biggest problem. For example,

• I want to avoid displaying blank page in my website after the new release(Fatal bugs but only need the least time to avoid).
• I want to reduce the high/critical bugs in the testing phase or production environment(Important for the DEV/QA team’s performance but only needs a little time to avoid)
• I want to keep the core functions available in any case(Depending on how many core functions you want to cover you may need some time)

Now, I’ll demo how to spend the least time to write an end-to-end test to solve the above problems.

Choose an e2e test frameworks

There’re many e2e test frameworks. I’ll compare them in another article, you can see a short comparison via this graph.

source

Because playwright is very convenient to demo, I’ll choose this one in this article.

Set up e2e tests

I create the test project using npm init playwright@latest. Also, I installed playwright vscode extension. These are the files created by playwrite.

Run the example tests

Now, I’ll run the example test through the start button provided by the vscode extension.

You can see the browsers opened and the test passed.

You can also see the test results in many places.

A brief conclusion

• As you can see, it’s extremely simple to run tests and see the running status(because the browser can be opened during the tests).

• Also, in the example test, we only need 3 lines to verify that the target websites is available and not displaying a blank page to users. If we deploy the tests to the CI QA and end users will have much lower chances of meeting a blank page.

You can also see the generated test reports. Please notice, we haven’t configured anything until now.

One step further

If playwright homepage is our own product, then we can summarize the core functions or smoke use cases

1. The homepage should be available, not displaying a blank page.
2. click the Docs should go to the document page
3. The document page should display the correct document.

Actually, there’re many remaining functions in the homepage, but the core functions are not too many. Since it’s a document website, the core function is that it is available and provides correct content.

If other functions are broken, it’s not that important. Even if found in the production environment, you may not be required to fix it urgently like in 1 hour.

That’s the truth in reality, not everything has the same importance.

If you do have enough time, of course, you can cover more cases. In that case, I guess you’re also required to write unit tests.

Anyway, based on my time budget and assumption, I’ll show you the code for the remaining test cases, less than 30 lines(including empty lines).

In real-world apps, to make element locating easier, we can add an attribute like data-testid in the testing element, then we can use something like

await page.getByTestId('nav-docs').click();

instead of

await page.locator('.navbar__link').getByText('Docs').click();

to make writing e2e tests even easier.

Last words

The only thing left now is to deploy the e2e test to your CI environment(Jenkins, Github Actions…). You can find the documents here.

If we deploy the e2e tests to our CI, according to this case only 30 lines of code can ensure that each push ad merge will not break the core functions. The risk of breaking the core functions by code will be much lower.

Writing e2e tests can also help you write automation scripts to solve life problems, not just good for development works.

So, do you want to write some e2e tests now?

We often use process.env to manage environment variables in front-end or Node.js projects.

How the env works in the front-end

In lots of cases, we’re using dotenv or cross-env to manage environment variables.

If you check the source code of dotenv, you will find that it assigns all the defined env variables to the process.env.

According to the document of Node.js.

It is possible to modify this object(process.env), but such modifications will not be reflected outside the Node.js process.

And cross-env will pass the target env to cross-spawn to launch a child process.

The child_process.spawn() method spawns a new process using the given command, with command line arguments in args.

In conclusion, the env variables set by dotenv or cross-env are only visible in the running Node.js process.

But it doesn’t matter normally because the env is set in the same process as the app or the app is running in a child process with the target env.

Thus if you open the Windows system environment variable dialog when your app is running, you will not see the defined env because it’s out of the app process.

If you set env by $env:TEST_ENV=dev in PowerShell or set TEST_ENV=dev in cmd, you will not get the expected value in another shell or cmd by $env:TEST_ENV or echo "%TEST_ENV%".

Change the env variable like editing in the Windows “environment variable dialog”

If you want to do this, you can use setx TEST_ENV dev in Powershell or cmd. Then open a new process(not a new child process) you will get the new TEST_ENV value.

For example, if you change the env out of vscode, you need to restart the vscode. Otherwise, even if you open a new shell in the vscode, you still can’t see the new env value.

If you don’t want to restart vscode you can use refreshenv in the vscode powershell or cmd after installing chocolatey(Package Manager for Windows). For example,

$env:TEST_ENV  # dev
setx TEST_ENV prod
$env:TEST_ENV  # dev, not change
refreshenv
$env:TEST_ENV # prod, changed

Since we can use setx to set the env variable permanently, we can also let Node.js execute the setx command. For example,

const { spawnSync } = require("child_process");
spawnSync('setx', ['-m', 'TEST_ENV', 'prod']);

In the script,

The child_process.spawnSync() method is generally identical to child_process.spawn() with the exception that the function will not return until the child process has fully closed.

Issue

Source

Reference