Forem: Maksim

JavaScript in IDE scripting console

Maksim — Wed, 18 Sep 2024 12:37:21 +0000

Official script example written in JavaScript

function main() {
  let sum = 0;
  let arr = "35907 77134 453661 175096 23673 29350".split(" ");
  arr.forEach((it) => sum += it.length);

  com.intellij.openapi.ui.Messages.showInfoMessage((sum / arr.length).toString(), "test");
}

main();

IDEA uses GraalJS to run the script. So you can use interop between JavaScript and Java to access Java objects.

JavaScript runtime also has a global variable IDE which reference an instance of com.intellij.ide.script.IDE

IDE.print("Hello World!")

Note: Setup Prometheus playground

Maksim — Sun, 10 Dec 2023 19:14:33 +0000

Download latest version of Prometheus from website and extract from archive, or just use script like this

PROME_VERSION="2.45.1" &&\
PROME_OS="darwin-amd64" &&\
PROME_FILE="prometheus-${PROME_VERSION}.${PROME_OS}.tar.gz" &&\
curl -L "https://github.com/prometheus/prometheus/releases/download/v${PROME_VERSION}/${PROME_FILE}" -o "/tmp/${PROME_FILE}" &&\
tar xvzf "/tmp/${PROME_FILE}" -C "/tmp"

Create Prometheus config file

cat > /tmp/prometheus.yml <<EOF
global:
  scrape_interval: 15s
  external_labels:
    monitor: 'codelab-monitor'

scrape_configs:
  - job_name: 'test'
    scrape_interval: 1s
    static_configs:
      - targets: ['localhost:3000']
EOF

Run Prometheus passing config file using --config.file argument

/tmp/prometheus-2.45.1.darwin-amd64/prometheus --config.file=/tmp/prometheus.yml

In our prometheus.yaml we have defined getting metrics from localhost:3000 . Let's create simple http server which hold metrics

cat > /tmp/index.js <<'EOF'
require('http').createServer(function (req, res) {
  if (req.url === '/metrics') {
    const metricName = 'foo';
    const metricType = 'gauge';
    const metricValue = 1;
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.write(`# TYPE ${metricName} ${metricType}\n`);
    res.end(`${metricName} ${metricValue}\n`);
    return;
  }
  res.writeHead(404, {'Content-Type': 'text/plain'});
  res.end('Not found\n');
}).listen(3000, () => console.log(new Date(), 'Listening on port 3000'));
EOF

Start server

node --watch /tmp/index.js

Open Prometheus graph UI

open http://localhost:9090/graph

Play with Prometheus 🎉

P.S.

Instead of handwritten server, you can use Pushgateway + curl

A one story about problem with partitioned table in PostgreSQL

Maksim — Wed, 01 Nov 2023 18:34:51 +0000

A one story about performance problem with partitioned table in PostgreSQL.

Let’s consider the use case where we have table “foo” and track history of changes in this table through trigger which write data to history table “foo_history”.

[app]
     -1. insert->[foo]
                   -2. after insert->[foo trigger]
                                               -3. insert->[foo_history]

“foo_history” uses partitions because potentially it could be big and data from this table would be deleted and collected in a cold storage from time to time. The simplest way to create a partition is create .. partition of..:

create table foo_history_p2 partition of foo_history for
  values from (<date-from>) to (<date-to>)

But this way requires ACCESS EXCLUSIVE lock on a parent table. This means that no other operations could be done on this table at the time when we create the partition. Usually, create partition does not take too much. But, what would be if in our application we use some kind of OLAP(Online Analytic Processing) queries over this history tables. For example, we collect some statistics and send it to a statistics server from time to time:

[app]
    -select->[foo_history]
                        -response->[app]
                                       -send->[statistics]

These queries can take some time to get a result from “foo_history” table. In our example, let’s consider that such query can take 5 seconds.

Now let’s return to our “foo” table. We use table “foo” often in our application, mostly to insert data. Queries over “foo” table should be small and fast. And all go well until we don’t get an alert that our insert queries in “foo” aborted duet timeout (from time to time). Looking on a database analytics, we see that those queries blocked and most of the time sit and waiting until lock would be released. What can goes wrong? We use simple insert statement which could not take too much time. And the load on the application is not so big so that we have problem with competing queries.

Time to remember about our trigger. Trigger runs in the same transaction as query. Every statement event simple INSERT INTO ... is wrapped in a transaction. We can’t commit a transaction until we finish all triggers. Let’s combine insert, trigger, select and create partition together in one chart:

[app]
    -1. select (5s)->[foo_history]
  [app]
      -2. create partition->[foo_history]
    [app]
        -3. insert->[foo]
                     -4. after insert->[foo_trigger]
                                                -5. insert->[foo_history]

We run statistic query over “foo_history” table
In a parallel starts the script which try to create a partition for “foo_history” table. Create partition take exclusive lock and wait util query (1) finished.
At this time goes request to insert data in table “foo”. We open transaction on insert.
Insert data and call “foo_trigger”
“foo_trigger” try to insert data in “foo_history” but because “create partition” took exclusive lock we're getting in line after “create partition” and waiting

so all request on insert in “foo” would wait until long query finished, and we create a partition even if this partition doesn’t necessary for these inserts.

Solution

We can move all read query on read only node (if we have master-follower scheme). Postgres allows adding CONCURRENTLY qualifier, but it still requires SHARE UPDATE EXCLUSIVE lock on the parent table.

Much better would be to create a partition table separately and after that attach it to the parent table. In this case, it would require SHARE UPDATE EXCLUSIVE lock on the partitioned table :

CREATE TABLE foo_history_p2 (LIKE foo_history INCLUDING ALL);

ALTER TABLE foo_history ATTACH PARTITION foo_history_p2 FOR
  VALUES FROM ('2023-12-01 00:00:00.000') TO ('2023-12-30 00:00:00.000');

Switch Node.js app to debug mode without restart

Maksim — Tue, 04 Apr 2023 15:31:40 +0000

Bootstrap simple Node.js app:

mkdir /tmp/echo-app && \
pushd /tmp/echo-app && \
mkdir src && \
npm init -y && \
npm install express

cat > src/index.js <<EOF
function main() {
  const express = require('express');
  const app = express();

  app.use((req, res) => {
    res.json({
      method: req.method,
      url: req.url,
      headers: req.headers
    });
  });

  app.listen(3000, () => {
    console.log('Server is running on port 3000');
  });
}

main();
EOF

Now let's run it:

node src/index.js

And try to switch it to debug mode without restarting. First, we should get node process ID for our application:

ps aux | grep node | grep src/index.js | awk '{print $2}'

now we can send SIGUSR1 to node process to switch node in debug mode:

kill -USR1 <pid>

Instead of kill command, you can use:

node -e 'process._debugProcess(<pid>)'

You can look at output where we have started our app. It should print:

Debugger listening on ws://127.0.0.1:9229/a22762b3-fd9e-4a74-99e5-41cf4a627e24
For help, see: https://nodejs.org/en/docs/inspector

Now we can attach a debugger to our running app. For example, you can open chrome://inspect/#devices in Chrome browser and see there as Remote Target your app. You can press inspect to open developer tools and set a breakpoint.

Developer tools with a breakpoint

To check that we’ll stop at breakpoint, you can send a request to the app.

curl localhost:3000/

Developer tools with debugger stopped on the breakpoint

To stop debug , you can just type in debugger console:

process._debugEnd()

VS Code: Debug node.js app in Kubernetes

Maksim — Sat, 18 Mar 2023 22:47:07 +0000

Story about how to debug node.js application on Kubernetes using VS Code.

I’ll use Minikube as a local Kubernetes cluster. Minikube allows playing with k8s without fear to break something.

Setup environment

Let’s create a simple express application. The first step is creating the app folder:

mkdir /tmp/app && \
pushd /tmp/app && \
npm init -y && \
npm install express && \
mkdir src

Now create index.js with simple express server:

cat > src/index.js <<EOF
function main() {
  const express = require('express');
  const app = express();

  app.get('/', (_, res) => {
    res.send('Hello World!!!');
  });

  app.listen(3000, () => {
    console.log('Example app listening on port 3000!');
  });
}

main();
EOF

Add Dockerfile for our simple app:

cat > Dockerfile <<EOF
FROM node:18-slim

WORKDIR /app

COPY package.json ./
COPY package-lock.json ./
COPY src ./src

RUN npm ci --only=production

EXPOSE 3000

CMD ["node", "src/index.js"]
EOF

Build node-app docker image:

docker build -t node-app .

Start Minikube

minikube start

Push our image to Minikube docker registry:

minikube image load node-app

Add deployment.yaml for Kubernetes cluster:

cat > deployment.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: node-app
  name: node-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: node-app
  template:
    metadata:
      labels:
        app: node-app
    spec:
      containers:
      - image: node-app
        name: node-app
        imagePullPolicy: Never
        resources: {
          limits: {
            cpu: 500m,
            memory: 512Mi
          }
        }
        ports:
          - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: node-service
spec:
  type: NodePort
  selector:
    app: node-app
  ports:
  - port: 3000
    targetPort: 3000
    nodePort: 30000
EOF

Create test namespace in:

kubectl create namespace test

Use test namespace by default for kubectl:

kubectl config set-context --current --namespace=test

Upload depolyment.yaml :

kubectl apply -f deployment.yaml

Check that our pods are running:

kubectl get pods

Start proxy Minikube to allow accessing our Kubernetes app from localhost. The following command will create a proxy, so don’t terminate it:

minikube service node-service --url -n test

Copy URL from previous command output and test that we can send a request to our pod from the localhost:

curl http://127.0.0.1:61127

Setup VS Code

Open /tmp/app folder in VS Code

code -n /tmp/app

Install Kubernetes extension for VS Code

code --install-extension ms-kubernetes-tools.vscode-kubernetes-tools --force

Run command in VS Code.

Kubernetes: Focus on Cluster View

There you should see minikube cluster. You can expand Workloads > Pods to see our running pods.

Now let’s open src/index.js the file and set the breakpoint on line:6 where we send the response res.send. Open command pallet and type:

 Kubernetes: Debug(Attach).

Select our pod
Select nodejs

VS Code will start node.js debug session inside our pod container. Now let’s check that we’ll stop at breakpoint by sending a request to our service:

curl http://127.0.0.1:61127

Look at VS Code, you should see that we have stopped on our breakpoint.

Stop on breakpoint inside Pod container

Now we can debug our deployed application on Kubernetes.

Develop local app inside Kubernetes

In previous section, we have learned how to debug deployed application, but we can’t modify it without rebuilding & redeploying the whole app. In this section, we set up a workflow so that we can proxy all Kubernetes requests to our local application, so we can develop our app inside Kubernetes environment.

Stop debug session from the previous section.

Install Bridge to Kubernetes extension for VS Code:

code --install-extension mindaro.mindaro --force

Open command pallet in VS Code and type

Bridge to Kubernetes: Configure

Select node-service
Enter port 3000. This is the port where we start our local app.
Select Configure Bridge to Kubernetes without a launch configuration
And No this will redirect all requests to our local machine. But Yes is helpful when you run it on shared Kubernetes cluster.

OK, now we have finished Bridge configuration. Let’s start our local application. You can start it in terminal:

node src/index.js

Or run in debug mode via VS Code

Debug: Start Debugging

Now run command:

Bridge to Kubernetes: Open Menu

And select Connect to the cluster. This command will modify Kubernetes deployment. And create an additional pod and job. This is required to proxy all request from Kubernetes node-app to local machine. You can see it by running:

kubectl get all

Or other Kubernetes introspection command. How does it work, in more details you can read here.

For now, let’s change res.send('Hello World!!!'); on res.send('Oh boy!!!') and run the same curl command to send request to our service:

curl http://127.0.0.1:61127

as a result, you will see

Oh boy!!!

so now you can develop and debug your application in live mode on Kubernetes 🎉

Compile Clojure to native binary using GraalVM

Maksim — Thu, 31 Mar 2022 18:17:14 +0000

We’ll write echo command on Clojure and compile it to native binary by GraalVM.

🥇 Setup

The first thing first. Create a project directory echo

mkdir /tmp/echo

add basic deps.edn

{:paths ["src"]
 :deps {org.clojure/clojure {:mvn/version "1.11.0"}}}

Create src/echo/main.clj. This would be our entry point:

(ns echo.main)

(defn -main [& args]
  (apply println args))

Run clj -M -m echo.main to be sure that all works fine

clj -M -m echo.main foo bar
foo bar

🥈 Build uberjar

Add build.clj to project’s root directory. This file contains logic how to build a Java jar

(ns build
  (:require [clojure.tools.build.api :as b]))

(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file "target/echo.jar")

(defn clean [_]
  (b/delete {:path "target"}))

(defn uberjar [_]
  (clean nil)
  (b/copy-dir {:src-dirs ["src"]
               :target-dir class-dir})
  (b/compile-clj {:basis basis
                  :src-dirs ["src"]
                  :class-dir class-dir})
  (b/uber {:class-dir class-dir
           :uber-file jar-file
           :basis basis
           :main 'echo.main }))

Now let’s add tools.build and :build task to deps.edn

{:paths ["src"]
 :deps {org.clojure/clojure {:mvn/version "1.11.0"}}
 :aliases {:build  
 {:deps  
 {io.github.clojure/tools.build {:git/tag "v0.8.1" :git/sha "7d40500"}}  
 :ns-default build}} }

And the last thing is to mark our echo.main as :gen-class

(ns echo.main
  (:gen-class))

(defn -main [& args]
  (apply println args))

Now we are ready to build uberjar

clj -T:build uberjar

This command will create a jar in the target folder. You can run it by java

java -jar target/echo.jar foo bar
foo bar

🥉 Build native

To build native script, we should install GraalVM after that we should add com.github.clj-easy/graal-build-time as a dependency to automate declaration of libraries by_ — initialize-at-build-time_

{:paths ["src"]
 :deps {org.clojure/clojure {:mvn/version "1.11.0"}
        com.github.clj-easy/graal-build-time {:mvn/version "0.1.4"}}
 :aliases
 {:build
  {:deps
   {io.github.clojure/tools.build {:git/tag "v0.8.1" :git/sha "7d40500"}}
   :ns-default build}}}

Rebuild jar

clj -T:build uberjar

and we are ready to run native-image to build binary

native-image -jar target/echo.jar --no-fallback --no-server target/echo

This command will generate a native binary from the jar to target/echo

Let’s test our binary

./target/echo foo bar

The end 🎉

Install GraalVM on macOS M1

Maksim — Thu, 31 Mar 2022 16:41:49 +0000

We can download required version of GraalVM using curl

curl --create-dirs --output-dir ~/Library/Java/JavaVirtualMachines -OL https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-22.0.0.2/graalvm-ce-java17-darwin-amd64-22.0.0.2.tar.gz

This command will download graalvm-ce-java17-darwin-adm64-22.0.0.2.tar.gz to ~/Library/Java/JavaVirtualMachines. Now we should extract archive’s content by tar

tar xvzf graalvm-ce-java17-darwin-amd64-22.0.0.2.tar.gz

Now we can add GRAALVM_HOME environment variables to .bashrc or .zshrc

export GRAALVM_HOME ="$HOME/Library/Java/JavaVirtualMachines/graalvm-ce-java17-22.0.0.2/Contents/Home"

also, we can add GraalVM bin folder to the PATH . This allows us to easily access executable commands from shell

export PATH="$GRAALVM_HOME/bin:$PATH"

Now we can easily install native-image using gu command

gu install native-image

Setup shadow-cljs react project

Maksim — Sun, 13 Mar 2022 16:47:16 +0000

🚀 Create project

The first step is create a project

npx create-cljs-project my-project

This command will create a project my-project with minimal required structure and install required dev dependencies for proper work of shadow-cljs

├── package-lock.json
├── package.json
├── shadow-cljs.edn
└── src
    ├── main
    └── test

shadow-cljs.edn is a configuration file for ClojureScript project

;; shadow-cljs configuration
{:source-paths
 ["src/dev"
  "src/main"
  "src/test"]

:dependencies
 []

:builds
 {}}

♺ Compile ClojureScript to JavaScript

Now, let’s create an entry point ClojureScript file

touch ./src/main/core.cljs

and add minimal boilerplate code to it

;; ./src/main/core.cljs
(ns core)

(defn main []
  (js/console.log "Hello World!"))

(main)

Now we should specify how to build the project. To do this, we should modify the :builds section in shadow-cljs.edn file

...

:builds
 {: **app** {:target : **browser**
        :modules {: **main** {:entries [**core**]}}}}}

:app is a build id
:browser is target’s type for generated JavaScript files
:main is a name of generated JavaScript file
core is a ClojureScript entry namespace

You can add :output-dir "public/js" to explicitly specify output directory for generated files by default shadow-cljs will use public/js

Now we can compile our ClojureScript to JavaScript files

npx shadow-cljs compile **app**

shadow-cljs - config: /private/tmp/my-project/shadow-cljs.edn
shadow-cljs - connected to server
[:app] Compiling ...
[:app] Build completed. (43 files, 0 compiled, 0 warnings, 0.33s)

👾 Start server

Now we are ready to setup the development server which will serve our static files. For this, we should return back to shadow-cljs.edn and add information about the dev server

:dev-http {8000 "public"}

8000 is a port which will be used by http server
public is a folder name for static files

Now we can start it by using watch command

npx shadow-cljs **watch** app

Beside the start http server watchcommand also automatically recompile JavaScript files when we change ClojureScript one

You can open http://localhost:8000 and see that the server is running

Not found. Missing index.html.

but complains on missing index.html. Let’s add index.html to the public folder

touch ./public/index.html

and add some minimal markup with reference to our generated JavaScript file

<!DOCTYPE html>
<html lang="">
  <head>
    <title>my-project</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
  </head>
  <body>
    <div id="app"></div>
    <script src=" **js/main.js**" type="text/javascript"></script>
  </body>
</html>

If we open developer tools in the browser we should see “Hello World!” message in the browser’s console. You can open core.cljs file and change the message. Browser automatically pickup the change via embedded to shadow-cljs live update functionality and display the new message

📦 Add React as dependency

shadow-cljs support npm dependencies, so here we can install react via npm

npm install react

Now we can use React in our ClojureScript application. Let’s print React’s version in the browser’s console. To do this, let’s modify core.cljs file

;; ./src/main/core.cljs
(ns core **(:require ["react" :as react])**)

(defn main []
  (js/console.log **(.-version react)**))

(main)

We can look at the console without restarting the server and see that now it displays React version

[Log] shadow-cljs: load JS – "node_modules/react/index.js"
[Log] shadow-cljs: load JS – "core.cljs"
[Log] 17.0.2

By the same way, we can install react-dom and render “Hello World!”

(ns core (:require 
           ["react" :as react]
           **["react-dom" :as react-dom]**))

(defn main []
  **(let [app-node (.getElementById js/document "app")]  
 (.render react-dom "Hello World!" app-node))** )

(main)

🎸 Reagent

We can use raw react and react-dom in our ClojureScript but it’s much better and less verbose to use Reagent is a minimalistic ClojureScript interface for React.

Because Reagent is a ClojureScript module, we can’t install it via npm. To install it, we should define required version in shadow-cljs.edn

:dependencies
 [**[reagent "1.1.1"]**]

Reagent is dependent from React & React DOM packages, so you still should install them via NPM.

Let’s update core.cljs code and replace React on Reagent

;; ./src/main/core.cljs
(ns core (:require 
          **[reagent.core :as r]  
 [reagent.dom :as rdom]** ))

**(defn app []  
 [:b "Hello World!"])**  

(defn main []
  (let [app-node (.getElementById js/document "app")]
    **(rdom/render [app] app-node)**))

(main)

Visual unit tests

Maksim — Mon, 27 Sep 2021 19:47:36 +0000

I hope that most of us use unit tests in day to day development because it saves a lot of time for us to make something new instead of repeat the same mistakes again. In this article, I'll talk about our approach to deal with visual tests

Retrospective and wishful thinking.

Standard approach

All visual tests* based on the same approach.

You should run the server with your application.
You should write tests which run by NodeJS
As a glue between our application and tests, we use Puppeteer or Playwright

Pros:

Expectation code is clean and straightforward

const image = await page.screenshot();
expect(image).toMatchImageSnapshot();

Cons:

Test code and code under tests are too far from each other In the test code, we usually call the driver to open some page where located code under test. In the best cases, such pages are somehow automatically generated. This led to notable switch between code under test and test itself that lead to frustration

  // Average visual regression test code
  const page = await browser.newPage(); // create a tab/page
  await page.goto('https://localhost:3000'); // navigate to URL where located the code which we want to test

Complicated setup and teardown. To run tests, we usually should set up two servers. One for code under test and another for tests itself
Usually such tests are slow due to complex setup and communication between test and code

All these problems and consequences prevent to write visual tests with pleasure. But visual problems haven't gone anywhere

What we want or ideal visual test for us

I always dreamed to have something similar to unit test experience. Where you can easily add or remove test. Play with code under tests by tweaking different options and observe the result. Focus on specific test and enjoy fast feedback loop between change and result

  render(<UserProfile/>) // code under test
  // test code
  const image = await page.screenshot(); // Take a screenshot
  expect(image).toMatchImageSnapshot(); // Test with reference

In the example above, our test code and what we want to test placed near each other. So by removing test, we're also removing code under test. We can experiment with test and code under test. Because it looks and behave as a regular unit test

Solution

For our unit tests, we use Karma because it's flexible, fast and solid tool to test frontend JavaScript in browser even after ~10 years of existing. Also, Karma would be our foundation for visual unit tests. So all approaches and tools which we can use and apply for unit tests are work for visual unit tests too. What we need is provide function to make a screenshot and matcher which compare reference with result.
To make it possible, we take Puppeteer or Playwright as launcher for our tests where we expose screenshot functionality and possibility to compare screenshot with reference image on the disk for our test code through expose function API.

We liked matcher functionality provided by jest-image-snapshot, so we just took this solution and adopted for jasmine and Karma.

The result is the boom of visual unit tests in our product. Because now write visual unit test as easy as write plain unit test

Conclusion

We love this approach because it already brings benefits of visual tests. And it does not require much effort. We pack it as a NPM package for karma, but what we love is the idea of having test code and code under test together, so you can look at our approach and maybe bring a more powerful tool. The repository itself contains tests, so you can open it via Gitpod or GitHub Codespace and play with it without additional setup.

- When we're building these tool there no cypress which such functionality but now as I know it provide something similar, and this is cool. Maybe in the future we would migrate to it, but for now we are happy with our current approach

Pitfalls

Font

An innate problem of visual test is a drawing font on different platforms. For us, we decided that in visual tests we want to test only visual part and text/font is more logical part, so we just create a custom font for visual tests where all symbols just black squares which works on all required platforms for us. So the developer can easily write a visual test on macOS and make a reference, and it would work for Linux.

Different browsers

Currently, we use only Puppeteer/Chrome to simplify the process of installation, reduce headache with different browsers and improve developer experience to encourage writing visual unit tests. It works for us because it already brings benefits. But solution support use of Playwright(Chromium/Edge, Safari, Firefox) so in the future if all would work fine and robust we are planing to run our tests on different browsers

Unit testing JavaScript with Karma. Playwright & Puppeteer

Maksim — Sat, 30 Jan 2021 17:12:51 +0000

Karma allows run tests in different browsers. In the basic setup, we assume that a developer has the required browser installed on the local machine. Such assumption complicates the test process because it requires manual work from the developer who wants to start writing tests and introduces a difference in a test environment that we could not control. For example, we decided that our unit tests should be run on a specific version of Chrome. Now we should somehow spread this knowledge in our team. This is an inefficient and error-prone approach.

One of the goals of an experienced engineer to simplify the process of setup and running tests for less experienced teammates. To encourage and spread test culture in the team. Puppeteer and Playwright allow us to simplify, automate and control the browser setup process.

Puppeteer

Let’s start from Puppeteer

npm install puppeteer

The Puppeteer would install chromium for the target platform automatically

Downloading Chromium r818858 - 132.4 Mb [====================] 100% 0.0s

Now let’s add downloaded Chromium as the default browser for Karma

process.env.CHROME_BIN = require('puppeteer').executablePath();

Because our default Karma config has karma-chrome-launcher we can reuse it to star Puppeteer’s Chromium simple define CHROME_BIN environment variable in the karma.conf.js

Let’s run our test and make sure that they pass, and we have not broken anything

npx karma start
30 01 2021 18:02:19.602:INFO [karma-server]: Karma v6.0.3 server started at [http://localhost:9876/](http://localhost:9876/)
30 01 2021 18:02:19.604:INFO [launcher]: Launching browsers Chrome with concurrency unlimited
30 01 2021 18:02:19.609:INFO [launcher]: Starting browser Chrome
30 01 2021 18:02:31.497:INFO [Chrome 88.0.4298.0 (Mac OS 11.0.0)]: Connected on socket -gzowZLOc2OrrmCUAAAB with id 15605462
Chrome 88.0.4298.0 (Mac OS 11.0.0): Executed 2 of 2 SUCCESS (0.011 secs / 0.003 secs)
TOTAL: 2 SUCCESS

Well. Now we can be sure that after run npm install a developer would have full-fledged test environment. We also can run Chrome without UI in headless mode by using ChromeHeadless as a default browser in karma.conf.js

browsers: ['ChromeHeadless'],

Now if you run npx karma start you would not see popped up Chrome window. This may be helpful if you run tests in watch mode to reduce visual noise.

In most cases, Puppeteer would be enough for unit tests. But what should we do if we want to run tests on Firefox or WebKit based browser like Safari? Here we can use Playwright

Playwright

Playwright beside Chrome automatically install Firefox and WebKit

npm install playwright

Downloading **chromium** v844399 - 98.5 Mb [====================] 100% 0.0s
chromium v844399 downloaded to /Caches/ms-playwright/chromium-844399
Downloading **firefox** v1225 - 73.9 Mb [====================] 100% 0.0s
firefox v1225 downloaded to /Caches/ms-playwright/firefox-1225
Downloading **webkit** v1423 - 51.3 Mb [====================] 100% 0.0s
webkit v1423 downloaded to /Caches/ms-playwright/webkit-1423

Let’s use Chrome installed by Playwright. What we need to do is just change CHROME_BIN in karma.conf.js

process.env.CHROME_BIN = require('playwright').chromium.executablePath();

It’s a good idea to rerun our tests to be sure that all works fine.

Setup for Firefox is not so different from Chrome. First we should install official karma-firefox-launcher plugin

npm install karma-firefox-launcher

update karma.conf.js by setting FIREFOX_BIN and changing browser on Firefox

process.env.FIREFOX_BIN = require('playwright').firefox.executablePath();
...
browsers: ['Firefox'],

run tests

npx karma start
30 01 2021 19:04:40.925:INFO [karma-server]: Karma v6.0.3 server started at [http://localhost:9876/](http://localhost:9876/)
30 01 2021 19:04:40.927:INFO [launcher]: Launching browsers **Firefox** with concurrency unlimited
30 01 2021 19:04:40.934:INFO [launcher]: Starting browser Firefox
30 01 2021 19:04:45.139:INFO [Firefox 85.0 (Mac OS 10.16)]: Connected on socket T1vGhzXoe8dhy_yxAAAB with id 60585180
Firefox 85.0 (Mac OS 10.16): Executed 2 of 2 SUCCESS (0.001 secs / 0.002 secs)
TOTAL: 2 SUCCESS

SUCCESS! 🎉

Now we can automatically install Chrome and Firefox for our tests without bothering a developer who want to write tests. Time to go and write some tests.

Unit testing JavaScript with Karma in 2021. Starting point

Maksim — Sat, 30 Jan 2021 13:43:42 +0000

Karma was born in the era of AngularJS. This was a significant improvement of existed test tooling on the Web and was one of the reasons for the spread of TDD in the JavaScript community. Karma still the best test runner for web JavaScript after almost 10 years thanks to the architecture and principles it’s based on.

Let's set up it for a test project and try to understand how it works. The first step is to install it via NPM

npm install karma

After successful installation, we would have Karma binary inside the local node_modules folder. Now let’s create the Karma configuration file for our project using the init command

npx karma init

Here we could select the testing framework from the list of popular frameworks like “Jasmine”, “Mocha” etc. In our example, we would use “Jasmine” so just press [Enter] to move to the next question.

Do you want to use Require.js ?
no

Require.js was popular 10 years ago for management dependencies when we didn’t have Webpack. Now it’s mostly rudiment so here we select [no]

Do you want to capture any browsers automatically ?
Press tab to list possible options. Enter empty string to move to the next question.
> Chrome

We would use Chrome as a default browser for our tests because this is one of the popular browsers nowadays and works on most of operating systems

What is the location of your source and test files ?
You can use glob patterns, eg. "js/*.js" or "test/**/*Spec.js".
Enter empty string to move to the next question.
> src/**/*.test.js
> src/**/*.js

Here we should tell Karma where we keep our source and test files. In our example, we would use src/**/*.test.js patter for test files which are widespread now, and src/**/*.js for source files

Should any of the files included by the previous patterns be excluded ?
You can use glob patterns, eg. "**/*.swp".
Enter empty string to move to the next question.
>

Leaves it empty

Do you want Karma to watch all the files and run the tests on change ?
Press tab to list possible options.
> yes

Karma can be run in two modes “single run” or “watch”. Single run means that when tests are finished karma would stop and to rerun our tests we should do run tests manually again. In the “ watch ” mode Karma would automatically rerun our tests when we change either the source or test files. This pretty handy feature saves our time , so we select [yes] here

Config file generated at "/<project>/karma.conf.js".

We have finished the configuration and Karma says that the result is a karma.conf.js file. But this is not all. Karma also has installed necessary dependencies based on our choices and updated package.json

+ "karma-chrome-launcher": "^3.1.0",
+ "karma-jasmine": "^4.0.1",

In our case these were

karma-chrome-launcher the plugin which helps run tests in Chrome
karma-jasmine an adapter for jasmine

Karma has a plugin architecture. Most of the language and frameworks specific functionality provided by plugins. Karma itself as a runner provides only functionality to run arbitrary JavaScript in a browser via Karma HTTP server. Also, Karma gives you the possibility to process your test and source files before they would be sent to the browser. So roughly say Karma is a mediator between your test/source files, frameworks, browsers, and operating system. Thus, this architecture allows karma to do only one thing but do it well and be open for extension without changing the Karma source itself. I highly encourage you to watch this video and look at the Karma source code itself as an example of a good product that stood the test of time.

Let’s move back to our test project and finish the Karma setup. Because we decided to use Jasmine as a test framework we should install it too.

npm install jasmine

karma-jasmine only a Karma adapter for Jasmine itself so this is why we should install Jasmine alongside karma-jasmine.

Now we are ready to write our first test. Let’s create a file src/foo.test.js and write a test case

describe('My first Karma test', function() {
  it('should be true', function() {
    expect(true).toEqual(true);
  });
});

Before start Karma make sure that you have installed Chrome which we select as our default browser for tests. Now we are ready to run our tests

npx karma start

This command would start the Karma server, open the Chrome browser, and run our tests. The result of tests would be printed in the terminal

30 01 2021 14:59:09.329:WARN [karma]: No captured browser, open [http://localhost:9876/](http://localhost:9876/)
30 01 2021 14:59:09.353:INFO [karma-server]: **Karma v6.0.3 server started at** [**http://localhost:9876/**](http://localhost:9876/)
30 01 2021 14:59:09.353:INFO [launcher]: Launching browsers Chrome with concurrency unlimited
30 01 2021 14:59:09.358:INFO [launcher]: Starting browser Chrome
30 01 2021 14:59:10.799:INFO [Chrome 88.0.4324.96 (Mac OS 11.1.0)]: Connected on socket kj6wu3FYg7XPKEKCAAAB with id 15222593
Chrome 88.0.4324.96 (Mac OS 11.1.0): Executed 1 of 1 SUCCESS (0.002 secs / 0.002 secs)
**TOTAL: 1 SUCCESS**

Here you can notice several interesting points

Karma starts the server
Open http://localhost:9876 in Chrome
Run tests and print the result

When tests finished Karma would not stop and wait for changes to rerun tests automatically. Let’s change our test to see how it works

it('should be true', function() {
  expect(true).toEqual( **false** );
});

And now look at the result

30 01 2021 15:02:37.443:INFO [filelist]: Changed file "/playground/src/foo.test.js".
Chrome 88.0.4324.96 (Mac OS 11.1.0) **My first Karma test should be true FAILED**
        Error: **Expected true to equal false**.
            at <Jasmine>
            at UserContext.<anonymous> ( **src/foo.test.js:3:18** )
            at <Jasmine>
Chrome 88.0.4324.96 (Mac OS 11.1.0): Executed 1 of 1 (1 FAILED) (6.226 secs / 0.001 secs)
**TOTAL: 1 FAILED, 0 SUCCESS**

You can see that Karma automatically rerun the test and told us that now we have 1 failed test. Also, the result contains useful information about the error. The error message contains

Name of a test suite. In our case My first Karma test
Name of a test case — test should be true
Expectation/assert error message — Expected true to equal false
Exception stack trace

Because Karma runs tests inside a browser you can use the browser’s developer tools to debug your tests. For this purpose, you can set a breakpoint in a test and open developer tools in Chrome. Also, you can open http://localhost:9876/debug page where tests would be run in the main window and don’t produce the result in the terminal. If you want to run your tests in another browser you can easily do it without stopping tests and changing configuration by open http://localhost:9876/ in an interesting browser. It would attach the browser to the Karma server and run tests on it too. This approach also allows you to run tests on any device and any browser just by opening Karma server URL.

Ok. Let’s fix our test by reverting to the previous change. To stop tests press [Ctrl-C] in the terminal where Karma is running. Now let’s change the Karma configuration file so that test runs without “watch” by default. To do this open karma.conf.js and change singleRun from false to true

singleRun: **true** ,

Now if we run tests again by npx karma start you can see Karma stops after tests finished. To run tests in watch mode we should pass --no-single-run parameter

npx karma start **--no-single-run**

When karma running in watch mode you can rerun tests without changing source and test files by run command. To do this we should open a new terminal window without terminating karma start process and run

npx karma run

This command mostly useful for the integration of different tools with Karma.

Now let’s talk about source files. In the example above we have added the test file that contains all logic inside itself. Let’s create the file src/foo.js and write function multiply

function multiply(x, y) {
  return x * y;
}

now let’s change add test inside src/foo.test.js so that it would check the result of function multiply

it('should multiply 2 on 2', function() {
  expect(multiply(2, 2)).toEqual(4);
});

If you don’t stop Karma server you can see that it automatically detect new file and test

Chrome 88.0.4324.96 (Mac OS 11.1.0): Executed 2 of 2 SUCCESS (0.006 secs / 0 secs)
TOTAL: 2 SUCCESS

Now we have two tests. You can see that function multiply available in the test file this is because all files are loaded and executed in the same context (on the same page). We had not restricted visibility of our function multiply thus it’s available globally, and we can use it in our test.

Here I finish the article. This is a basic setup of Karma and starting point for advanced configuration. I recommend starting from the basic setup and when you are sure that it works correctly move towards advanced configuration which usually includes preprocessing step for web projects in our days.

Handling events in React

Maksim — Sat, 11 Jan 2020 18:20:02 +0000

Handling events with React elements is very similar to handling events on DOM elements. There are some syntactic differences

This is what React documentation says. But besides syntactic differences you can face the problem that handling works differently too.

Let’s take a look at the examples from the official documentation:

The HTML version

<button onclick="activateLasers()">
  Activate Lasers
</button>

And the React version

<button onClick={activateLasers}>
  Activate Lasers
</button>

In both cases if we click on the button, the activateLasers function would be called. With the difference in when it is going to be called.

In the HTML version activateLasers is called on the button element and in the React version activateLasers is be called on the document element.

Why does it matter?

Usually the document element is the last element in the chain of elements which participate in an event handling[1]. So you can see the situation when the click handler on an ancestor element would be fired before the click handler on an descendent element. Usually you can face this problem if you use React with another non React libraries which could listen to DOM events.

I hope this small note would be helpful and will save you a lot of headache down the line if you face this inconsistency between DOM and React event handling.

[1] - Here I’m talking about event bubbling phase