DEV Community: Andrei Rusu

Test your React Components with Nightwatch and Testing Library

Andrei Rusu — Sun, 08 Jan 2023 16:46:28 +0000

Component testing in Nightwatch has been refined with version 2.4 and support for testing React components (via the @nightwatch/react plugin) has been significantly improved. We also released a new plugin for using the popular Testing Library with Nightwatch - @nightwatch/testing-library, available since Nightwatch v2.6.

We're now going to build a detailed example of how to use Nightwatch and Testing Library to test React components. We'll be Complex example available on the React Testing Library docs, which is written with Jest.

In this tutorial, we'll cover how to:

set up a new React project with Vite, which is also what Nightwatch uses internally for component testing;
install and configure Nightwatch and Testing Library;
mock API requests using the @nightwatch/api-testing plugin;
write a complex React component test using Nightwatch and Testing Library.

Step 0. Create a new project

To get started, we'll create a new project with Vite:

npm init vite@latest

Select React and JavaScript when prompted. This will create a new project with React and JavaScript.

Step 1. Install Nightwatch and Testing Library

Testing Library for React can be installed with the @testing-library/react package:

npm i @testing-library/react --save-dev

To install Nightwatch, run the init command:

npm init nightwatch@latest

Select Component testing and React when prompted. This will install nightwatch and the @nightwatch/react plugin. Choose a browser to install the driver for. We'll be using Chrome in this example.

1.1. Install @nightwatch/testing-library plugin

Since v2.6, Nightwatch provides its own plugin for using the Testing Library queries directly as commands. We're going to need it to write our test later on so let's install it now:

npm i @nightwatch/testing-library --save-dev

1.2 Install @nightwatch/apitesting plugin

The example contains a mock server that is needed to test the component. We'll be using the integrated mock server that comes with the @nightwatch/apitesting plugin. Install it with:

npm i @nightwatch/apitesting --save-dev

Step 2. Create the Login component

We'll use the same component as in the React Testing Library docs. Create a new file src/Login.jsx and add the following code:

// login.jsx
import * as React from 'react'

function Login() {
  const [state, setState] = React.useReducer((s, a) => ({...s, ...a}), {
    resolved: false,
    loading: false,
    error: null,
  })

  function handleSubmit(event) {
    event.preventDefault()
    const {usernameInput, passwordInput} = event.target.elements

    setState({loading: true, resolved: false, error: null})

    window
      .fetch('/api/login', {
        method: 'POST',
        headers: {'Content-Type': 'application/json'},
        body: JSON.stringify({
          username: usernameInput.value,
          password: passwordInput.value,
        }),
      })
      .then(r => r.json().then(data => (r.ok ? data : Promise.reject(data))))
      .then(
        user => {
          setState({loading: false, resolved: true, error: null})
          window.localStorage.setItem('token', user.token)
        },
        error => {
          setState({loading: false, resolved: false, error: error.message})
        },
      )
  }

  return (
    <div>
      <form onSubmit={handleSubmit}>
        <div>
          <label htmlFor="usernameInput">Username</label>
          <input id="usernameInput" />
        </div>
        <div>
          <label htmlFor="passwordInput">Password</label>
          <input id="passwordInput" type="password" />
        </div>
        <button type="submit">Submit{state.loading ? '...' : null}</button>
      </form>
      {state.error ? <div role="alert">{state.error}</div> : null}
      {state.resolved ? (
        <div role="alert">Congrats! You're signed in!</div>
      ) : null}
    </div>
  )
}

export default Login

Step 3. Create the component test

One of the founding principles of Testing Library is that tests should resemble how users interact with the application as much as possible. When writing component tests in Nightwatch using JSX, we need to write the test as a component story using the Component Story Format, a declarative format introduced by Storybook.

This enables us to write tests that focus on how the component is used, rather than how it's implemented, which is in line with the Testing Library philosophy. You can read more about this in the Nightwatch docs.

The great thing about using this format to write our tests is that we can use the same code to write stories for our components, which can be used to document and showcase them in Storybook.

3.1 Login with valid credentials test

Create a new file src/Login.spec.jsx and add the following code, which does the same as the complex example written with Jest:

To render the component using JSX in Nightwatch, we simply create an export for the rendered component, optionally with a set of props. The play and test functions are used to interact with the component and verify the results.

play is used to interact with the component. It's executed in the browser context, so we can use the screen object from Testing Library to query the DOM and fire events;
test is used to verify the results. It's executed in the Node.js context, so we can use the Nightwatch browser object to query the DOM and verify the results.

// login.spec.jsx
import {render, fireEvent, screen} from '@testing-library/react'
import Login from '../src/login'

export default {
  title: 'Login',
  component: Login
}

export const LoginWithValidCredentials = () => <Login />;
LoginWithValidCredentials.play = async ({canvasElement}) => {
  //fill out the form
};

LoginWithValidCredentials.test = async (browser) => {
  // verify the results
};

Add the mock server

The example uses a mock server to simulate a login request. We'll be using the integrated mock server that comes with the @nightwatch/apitesting plugin.

For this we'll use the setup and teardown hooks which we can write directly in the test file. Both hooks are executed in the Node.js context.

We also need to set login endpoint to http://localhost:3000/api/login in the Login component, which is the url to the mock server.

Complete test file

The complete test file will look like this:

// login.spec.jsx
import {render, fireEvent, screen} from '@testing-library/react'
import Login from '../src/Login'

let server;
const token = 'fake_user_token';
let serverResponse = {
  status: 200,
  body: {token}
};

export default {
  title: 'Login',
  component: Login,
  setup: async ({mockserver}) => {
    server = await mockserver.create();
    server.setup((app) => {
      app.post('/api/login', function (req, res) {
        res.status(serverResponse.status).json(serverResponse.body);
      });
    });

    await server.start(mockServerPort);
  },

  teardown: async (browser) => {
    await browser.execute(function() {
      window.localStorage.removeItem('token')  
    });

    await server.close();
  }
}

export const LoginWithValidCredentials = () => <Login />;
LoginWithValidCredentials.play = async ({canvasElement}) => {
  //fill out the form
  fireEvent.change(screen.getByLabelText(/username/i), {
    target: {value: 'chuck'},
  });

  fireEvent.change(screen.getByLabelText(/password/i), {
    target: {value: 'norris'},
  });

  fireEvent.click(screen.getByText(/submit/i))
};

LoginWithValidCredentials.test = async (browser) => {
  const alert = await browser.getByRole('alert')
  await expect(alert).text.to.match(/congrats/i)

  const localStorage = await browser.execute(function() {
    return window.localStorage.getItem('token');
  });

  await expect(localStorage).to.equal(fakeUserResponse.token)
};

Debugging

One of the main benefits of using Nightwatch for component testing, besides having the same API available for end-to-end testing, is that we can run the tests in a real browser, instead of a virtual DOM environment, such as JSDOM.

This allows us to use the Chrome Dev Tools to debug the tests.

For example, let's go ahead and add a debugger statement in the LoginWithValidCredentials.play function:

LoginWithValidCredentials.play = async ({canvasElement}) => {
  //fill out the form
  fireEvent.change(screen.getByLabelText(/username/i), {
    target: {value: 'chuck'},
  });

  fireEvent.change(screen.getByLabelText(/password/i), {
    target: {value: 'norris'},
  });

  debugger;

  fireEvent.click(screen.getByText(/submit/i))
};

Now, let's run the test with --debug and --devtools flags:

npx nightwatch test/login.spec.jsx --debug --devtools

This will open a new Chrome window with the Dev Tools open. We can now set a breakpoint in the Dev Tools and step through the code.

3.2 Login with server exception test

The original example from the TestingLibrary docs also includes a test for the case when the server throws an exception.

Let's try to write the same in Nightwatch. This time we'll use just the test function, since we can interact with the component this way as well. As we've mentioned earlier, the test function is executed in the Node.js context, and it receives the Nightwatch browser object as argument.

We'll also need to update the mock server response to return a 500 status code and an error message. This we can easily accomplish by writing a preRender test hook on the LoginWithServerException component story.

export const LoginWithServerException = () => <Login />;
LoginWithServerException.preRender = async (browser) => {
  serverResponse = {
    status: 500,
    body: {message: 'Internal server error'}
  };
};

LoginWithServerException.test = async (browser) => {
  const username = await browser.getByLabelText(/username/i);
  await username.sendKeys('chuck');

  const password = await browser.getByLabelText(/password/i);
  await password.sendKeys('norris');

  const submit = await browser.getByText(/submit/i);
  await submit.click();

  const alert = await browser.getByRole('alert');
  await expect(alert).text.to.match(/internal server error/i);

  const localStorage = await browser.execute(function() {
    return window.localStorage.getItem('token');
  });

  await expect(localStorage).to.equal(token)
};

4. Run the test

Finally, let's run the test. This will run the LoginWithValidCredentials and LoginWithServerException component stories in Chrome.

npx nightwatch test/login.spec.jsx

To run the test without opening the browser, we can pass the --headless flag.

If all goes well, you should see the following output:

[Login] Test Suite
────────────────────────────────────
ℹ Connected to ChromeDriver on port 9515 (1134ms).
  Using: chrome (108.0.5359.124) on MAC OS X.

Mock server listening on port 3000

  Running <LoginWithValidCredentials> component:
──────────────────────────────────────────────────────────────
[browser] [vite] connecting...
[browser] [vite] connected.
  ✔ Expected element <LoginWithValidCredentials> to be visible (15ms)
  ✔ Expected element <DIV[id='app'] > DIV > DIV> text to match: "/congrats/i" (14ms)
  ✔ Expected 'fake_user_token'  to equal('fake_user_token'): 

  ✨ PASSED. 3 assertions. (1.495s)

  Running <LoginWithServerException> component:
──────────────────────────────────────────────────────────────
[browser] [vite] connecting...
[browser] [vite] connected.
  ✔ Expected element <LoginWithServerException> to be visible (8ms)
  ✔ Expected element <DIV[id='app'] > DIV > DIV> text to match: "/internal server error/i" (8ms)
  ✔ Expected 'fake_user_token'  to equal('fake_user_token'): 

  ✨ PASSED. 3 assertions. (1.267s)

  ✨ PASSED. 6 total assertions (4.673s)

5. Conclusion

That's it! You can find the complete code for this example in the GitHub repository. PRs are welcome.

Fell free to drop by the Nightwatch Discord if you have any questions or feedback.

Create, Test and Deploy a Single Page App with Vue 3 + Vite and Pinia

Andrei Rusu — Mon, 07 Feb 2022 08:56:51 +0000

Introduction

Created in 2014, Vue.js is undoubtedly one of the leading frontend frameworks at the moment and with a growing community and expanding ecosystem it seems that its position is firm for quite some time. I have worked with Vue 2 several years ago for a few projects and I found it a delightful experience.

I thought now it’s the time to upgrade my tool-set with the latest version and also with newer tools like Vite and Pinia.

This guide will cover in detail the steps to create a functional example bookstore single page application using Vue 3 and run it using Vite. It also includes details on how to add state management using Pinia (the Vuex successor) and routing using Vue Router.

The core concepts that will be covered are:

creating a Vue 3 single page application using Vite
managing routes with Vue Router
managing application state with Pinia
running, building and deploying the app with Vite
writing and running Vue component tests
writing and running automated end-to-end tests with Nightwatch.js

This may seem like a lot but I think it’s perfectly possible to go through all of it in less than 20 minutes. Some of the topics listed above could be expanded into entire tutorials of their own, but for now I am covering only what’s needed to have everything up and running.

One last thing that needs to be mentioned is that the backend is not covered in this tutorial. There is no server side component per se, although the data is loaded using the browser Fetch API (the successor of XHR) so a backend component could be easily added.

For all accounts and purposes, the application we’ll build here can be deployed as a static website. If you're eager to get right down to coding and you'd like to jump into it right away, you can just get the project up and running with:

git clone https://github.com/beatfactor/middlemarch
npm install
npm run dev

Or fork the project on Github at: https://github.com/beatfactor/middlemarch

Step 1 – Setting Up the Application with the `create-vite` Scaffolding Tool

We’re going to use the official create-vite scaffolding tool to setup the project structure so make sure you have Node 12+ installed with NPM 6+. They also support Yarn and PNPM as package managers, but we’ll only cover NPM.

The create-vite tool will also create the project folder for you, so just make sure to cd into the parent folder first: cd ~/workspace

Install Vite and initialise the project with:

npm init vite@latest

Then you’ll be prompted to enter the project name and select the library which you want to use. From the list, choose vue:

~/workspace % npm init vite@latest
npx: installed 6 in 1.051s
✔ Project name: … vue-bookstore
? Select a framework: › - Use arrow-keys. Return to submit.
    vanilla
❯   vue
    react
    preact
    lit
    svelte

Then select vue as the variant, since we’ll not be using TypeScript:

? Select a variant: › - Use arrow-keys. Return to submit.
❯   vue
    vue-ts

You should see the following output:

npx: installed 6 in 1.051s
✔ Project name: … vue-bookstore
✔ Select a framework: › vue
✔ Select a variant: › vue

Scaffolding project in /Users/andrei/workspace/vue-bookstore...

Done. Now run:

  cd vue-bookstore
  npm install
  npm run dev

Once we have followed the above instructions, we’ll get the following output from Vite telling us that the app is running:


  vite v2.7.7 dev server running at:

  > Local: http://localhost:3000/
  > Network: use `--host` to expose

  ready in 611ms.

Let’s visit the localhost:3000 url. The welcome page looks like this:

Step 2 – Adding routing with Vue Router and state management with Pinia

Let’s review the project’s directory structure created by the create-vite tool:

vue-bookstore/
 ├── public/
 |    ├── favicon.ico
 ├── src/
 |    ├── assets/
 |    |    └── logo.png
 |    ├── components/
 |    |    └── HelloWorld.vue
 |    ├── App.vue
 |    └── main.js
 ├─── package.json
 ├─── README.md
 └─── vite.config.js

In this section of our guide, we’ll be adding two new dependencies to our project: vue-router and pinia. Let’s go ahead and install them from NPM.

Vue Router

Vue Router is the official router for Vue.js. We’ll need to install version 4 which is compatible with Vue 3:

npm install vue-router@4 --save

Pinia

Pinia is one of the newest projects to emerge from the Vue ecosystem and it’s the new official state management tool for Vue.js apps. It’s api is very similar to Vuex (its predecessor) and it is designed to be faster and more lightweight.

You can install pinia from NPM with:

npm install pinia --save

Setting Up Routing

If you’re unfamiliar with routing in a single page application or state management, don’t worry; both of these concepts are very easy to understand and they will be self explained once you see how it works.

Also, remember that we are just building a tutorial here and the goal is to have everything up and running in 20 minutes and that doesn’t require learning all there is to know about Vue.js. It doesn’t even require understanding everything we’ll be doing.

What is a Single Page Application?

Since we’re building a single page application here, it might be useful (though not essential) to consider what that means and why is it single page.

A single page application is simply a web application that doesn’t reload the page when you navigate to another of its sub-pages. The url of the browser is modified though, as if the page has been reloaded, and that's done using the HTML5 History API.

Working with Vue Components in Vite

The scaffolding created using the create-vite tool adds a very basic Vue component, located in src/components/HelloWorld.vue. It is then being used in the main application component, located in src/App.vue.

There are two other important files:

index.html
src/main.js

The index.html file is what the browser sees when it navigates to our application’s page and the main.js is the entry point for the Vue.js app.

Here’s how these files look like:

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" href="/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite App</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.js"></script>
  </body>
</html>

src/main.js

import { createApp } from 'vue'
import App from './App.vue'

createApp(App).mount('#app')

Adding Routes

It’s time now to create our application’s main routes. In Vue, every route must correspond to a component. For this application, we’ll consider a component per subpage, like so:

Homepage - our bookstore homepage
Cart - the shopping cart and check out page
Sign-In - the user sign-in page

Since this is only an example, other pages like user sign-up or product detail page, have been left out. Also, the sign-in page is only contains only a mock sign-in.

For basic HTML and CSS, I’ve also used Bootstrap 5 for things like UI dropdowns and forms, but of course you can use whatever UI library you want.

We’ll create the page components empty for now so we can setup the routing. The new src directory structure will look like this (after removing the boilerplate code):

src/
  ├── components/
  |    └── TopNavbar.js
  ├── lib/
  |    ├── router.js   
  |    └── store.js
  ├── pages/
  |    ├── cart/
  |    |    ├── cart.css
  |    |    ├── cart.html
  |    |    └── Cart.vue
  |    ├── home/
  |    |    ├── home.css
  |    |    ├── home.html
  |    |    └── Home.vue
  |    ├── sign-in/
  |    |    ├── sign-in.css
  |    |    ├── sign-in.html
  |    |    └── SignIn.vue
  |    └── routes.js
  ├── App.vue
  └── main.js

We’ve added three pages, each of which we’ll keep very basic. We’ll just add TobNavbar component to make the navigation working without page reloads.

Add the following for src/pages/cart/Cart.vue, src/pages/home/Home.vue and src/pages/sign-in/SignIn.vue:

<script setup>
import TopNavbar from '../../components/TopNavbar.vue';
</script>

<template>
  <TopNavbar />
</template>
<style></style>

<script>
export default {
  components: {
    TopNavbar
  },

  computed: {},

  mounted() {
  },

  data() {
    return {
    };
  },
};
</script>

The TopNavbar component located in src/components will contain just the navigation links. Notice the router-link component which is part of the vue-router:

<template>
  <router-link to="/">Home</router-link>
  <router-link to="/cart/">Cart</router-link>
  <router-link to="/sign-in/">Sign In</router-link>
</template>

The pages/routes.js file contains all the route declarations for the application. Here’s how it looks like:

import {createRouter} from 'vue-router'
import Homepage from './home/Home.vue';
import SignIn from './sign-in/SignIn.vue';
import Cart from './cart/Cart.vue';

const routes = [
  {
    path: '/',
    component: Homepage
  },

  {
    path: '/sign-in/',
    component: SignIn
  },

  {
    path: '/cart/',
    component: Cart
  },
]

export default function (history) {
  return createRouter({
    history,
    routes
  })
}

Before we’re ready to see the vue-router in action we just need to do 2 more things:

1) Create the router and add it to the main Vue application instance, in src/main.js:

import { createApp } from 'vue'
import { createWebHistory } from 'vue-router'

import createRouter from './pages/routes.js'
import App from './App.vue'

const router = createRouter(createWebHistory())
const app = createApp(App)
app.use(router).mount('#app')

2)Add the <router-view> component in src/App.vue:

<template>
  <router-view></router-view>
</template>

Now re-run npm run dev if needed and then navigate to http://localhost:3000 and you’ll have a routing enabled Vue 3 app.

Setting Up State Management Using Pinia

Moving on, now we need to set up the Pinia store for our app. The store is where the application state is maintained.

Pinia is a new project from the Vue.js core team and is now the recommended approach for working with the application state. If you’re already familiar with Vuex, getting used to Pinia will be straightforward. In fact, the Pinia api is slightly easier and less verbose than Vuex.

With Pinia, in a Vue 3 app there is one root store and then any number of individual stores. For our bookstore app, we’re going to use only two stores:

the catalog store: a list of available books
the cart store: books that the user wants to order

Creating a Pinia

A “pinia” is the root store that we have to create first and pass it to the Vue instance.

We’ll do that in src/main.js and update it to look like:

import { createApp } from 'vue'
import { createWebHistory } from 'vue-router'
import { createPinia } from 'pinia'

import createRouter from './pages/routes.js'
import App from './App.vue'

const store = createPinia()
const router = createRouter(createWebHistory())
const app = createApp(App)

app.use(router).use(store).mount('#app')

Next step is to create the individual catalog and cart stores and use them in components.

Adding the Catalog Store

Creating a Pinia store means two things mainly:

defining the store
using the store in one or more components

Defining the Store

Like Vuex, the Pinia store contains the state and two types of methods: getters and actions.

Some things to consider about a store:

Getters are synchronous functions used to retrieve data from the state
Actions are functions that can also be asynchronous which are used to update the state
The state is defined as a function returning the initial state

It’s time now to create the catalog store inside src/stores/catalog.js:

import { defineStore } from 'pinia'

export const useCatalog = defineStore('catalog-store', {
  state: () => {
    return {
      newArrivals: [],
      fetching: false
    }
  },

  getters: {
    results(state) {
      return state.newArrivals;
    },

    isFetching(state) {
      return state.fetching;
    }
  },

  actions: {
    async fetchNewArrivals() {
      this.fetching = true;
      const response = await fetch('/data/new-arrivals.json');
      try {
        const result = await response.json();
        this.newArrivals = result.books;
      } catch (err) {
        this.newArrivals = [];
        console.error('Error loading new arrivals:', err);
        return err;
      }

      this.fetching = false;
    }
  }
})

Looking at the above source code, you’ll notice we have two getters (results and isFetching) and one action (fetchNewArrivals). Instead of a real backend we just have a json file located in /data/new-arrivals.json which contains a few books that we’ll use as our catalog.

You’ll also notice that our getters don’t do anything special with the data and so they’re a bit unnecessary, but I thought it’s still good to show how you can define them.

Using the Store in a Template

Linking the above definition to a template is also quite straightforward.

Let’s create a new component called NewArrivals inside src/components/NewArrivals.vue which we’ll use it the Home.vue page component.

<script setup>
import {useCatalog} from '../../store/catalog.js'
</script>

<template>

</template>

<style scoped></style>
<script>
import { mapState, mapActions } from 'pinia'

export default {
  computed: {
    ...mapState(useCatalog, {newArrivals: 'results'})
  },

  methods: {
    ...mapActions(useCatalog, ['fetchNewArrivals']),

    addToCart() {
      // we'll populate this later
    }
  },

  created() {
    // when the template is created, we call this action
    this.fetchNewArrivals();
  }
};
</script>

And the Home.vue component becomes:

<script setup>
import TopNavbar from '../../components/TopNavbar.vue';
import NewArrivals from '../../components/NewArrivals.vue';
</script>

<template>
  <TopNavbar />
  <NewArrivals />
</template>

<style></style>

<script>
export default {
  components: {
    TopNavbar,
    NewArrivals
  },
  computed: {},
  mounted() {},
  data() {
    return {};
  },
};
</script>

Here’s a diagram of how the store and the component work together in the application:

I also wrote a store and a component for the cart but I will not include it in the tutorial because the mechanism is similar and you can inspect the source code in the repository which has everything added together, even some styles.

Step 3 – Testing Vue.js Components

Component testing is a type of UI testing where the component is rendered in isolation, without the rest of app components, for the purpose of verifying its functionality. It’s usually a testing strategy which happens prior the end-to-end testing step, which we’ll elaborate in the next section.

We need to install the Vue TestUtils project, which is the official unit testing library for Vue.js and we need the one that targets Vue 3. You can install that from NPM with:

npm install @vue/test-utils@next --save-dev

Installing Nightwatch.js and ChromeDriver

We’ll use Nightwatch.js for both component testing and end-to-end testing. Nightwatch is already one of the recommended testing frameworks by the Vue.js team and was published around the same time as Vue.

It has recently gotten support (still in beta at the moment) for Vue component testing through the vite-plugin-nightwatch. We’ll go ahead an install Nightwatch v2 using:

npm install nightwatch--save-dev

And we’ll also need the vite-plugin-nightwatch mentioned earlier:

npm install vite-plugin-nightwatch --save-dev

Nightwatch uses the W3C WebDriver API for browser automation tasks and we’ll need to install the chromedriver NPM package as well, because we’re going to use Chrome to run our tests.

npm install chromedriver --save-dev

Testing the <NewArrivals> Component

And with that, we have arrived at the point where we can finally start writing the actual test for our NewArrivals component.

The vite-plugin-nightwatch mentioned earlier includes a test renderer page and Nightwatch already contains everything needed for running the initial test for our component.

Create a folder test and inside it two subfolders:

component - this will hold component tests
e2e - this will hold end-to-end tests

We also need a nightwatch.conf.js configuration file, but we can run Nightwatch directly and the config file will be created for us automatically. Just make sure chromedriver is also installed (and the Chrome browser, of course).

Make sure the current working directory is the project root and then simply run an example test which are bundled with Nightwatch. We’ll pick the duckDuckGo test because it’s the fastest:

$ npx nightwatch examples/tests/duckDuckGo.js

The project structure should look like this now:

vue-bookstore/
 ├── public/
 |    ├── data/
 |    └── favicon.ico
 ├── src/
 ├── ...
 |    └── main.js
 ├── test/
 |    ├── component/
 |    └── e2e/
 ├─── nightwatch.conf.js
 ├─── package.json
 ├─── README.md
 └─── vite.config.js

We’ll go ahead and create a new file called newArrivalsTest.js inside test/component. In it, we’ll just add a basic test which mounts the component and checks if the returned element can be found in the page (i.e. the component has been mounted).

describe('New Arrivals Component Test', function() {

  it('checks if the component has been mounted', async (browser) => {
    const component = await browser.mountVueComponent('/src/components/new-arrivals/NewArrivals.vue', {
      plugins: {
        router: '/src/lib/router.js'
      }
    })
    expect(component).to.be.present; 
  });
});

Nightwatch uses the same describe() syntax as Mocha. You can even use Mocha as a test runner if you’re already familiar with it, but we’re not going to do that for now. In case you’d like to use Mocha, you only need to slip a few switches in the nightwatch config file and there’s documentation available on the Nightwatch website on how to do that.

It’s time now to run the above test and for that we’ll run Nightwatch using Chrome, like so:

npx nightwatch test/component/newArrivalsTest.js --env chrome

This will open the Chrome browser and render the component, then perform the test. If you don’t like seeing the browser window pop up during the test, you can pass the --headless argument, like so:

npx nightwatch test/component/newArrivalsTest.js --env chrome --headless

The test output should look like below:

[New Arrivals Component Test] Test Suite
──────────────────────────────────────────────────────────────
ℹ Connected to ChromeDriver on port 9515 (652ms).
  Using: chrome (97.0.4692.99) on MAC OS X.


  Running tests the component:
──────────────────────────────────────────────────────────────
  ✔ Expected element <web element{e53f9b1e-11d3-4dc4-8728-4d3cd077343e}> to be present (1ms)

OK. 1 assertions passed. (781ms)

You can of course consult all the CLI options that the Nightwatch runner provides, either by going to the docs pages or by running:

npx nightwatch --help

Extending the <NewArrivals> Test

You may have noticed that our component test isn’t testing that much which means that the test is not as helpful as it could be. So we’ll go ahead and extend it only a little bit.

We’ll just inspect the NewArrivals component and check if there is a property in it called newArrivals, which is used in the html to render the results.

The test looks like this now. We’ve refactored the component mounting into the the before hook so we can only do the checks inside the test, which is the it block. The expect library is provided by Nightwatch out of the box and it is based on the popular and versatile Chai.js assertion library. More info on how to use the expect on the Nightwatch docs website.

describe('New Arrivals Component Test', function() {

  let component;

  before(async () => {
    component = await browser.mountVueComponent('/src/components/new-arrivals/NewArrivals.vue', {
      plugins: {
        router: '/src/lib/router.js'
      }
    })
  });

  it('checks if the component has been mounted', function(browser) {
    expect(component).to.be.present;
    expect(component).to.have.property('newArrivals');
    expect(component).text.toContain('The Memory Police')

    expect.elements('div.col-md-6').count.toEqual(4);       expect(component.property('newArrivals')).to.be.an('array').with.length(1);   
  });
});

Step 4 – End-to-End Testing the Vue.js App

We are nearing the end of this tutorial and before we can consider we have a working Vue.js app, we need to add support for end-to-end testing and setup a CI pipeline on Github Actions.

Fortunately we don’t need to install, nor configure, any other tools, unless maybe some fancy reporters, but for now we can get everything we need in terms of end-to-end automated testing out of Nightwatch. Besides Chrome, Nightwatch has built-in support for all major browsers, including Firefox, Edge, and Safari, all thanks to its integration with the W3C Webdriver API and Selenium. It also allows you to use distributed cloud testing platforms like BrowserStack, SauceLabs, CrossBrowserTesting, or LambdaTest.

For now, we’ll just keep things less complex and we’ll only focus on writing a few basic automated tests and run them in Chrome, Firefox, and Safari.

Writing the Homepage End-to-end Test

Let’s get started with the homepage end-to-end test and create a new file under test/e2e/homePageTest.js. The syntax is the same as for the component test, but for running the end-to-end tests we’ll use the compiled build of our application.

We can of course run them against the dev build, but the established practice in software development, as far as I can tell, is to run the end-to-end tests in an environment which simulates the production as close as possible. Which is why they’re called end-to-end tests I suppose, to run them against the end product.

Running the Production Build

To run the production build we have to options and each of them involve running a Vite command, which is wrapped in an NPM tasks.

npm run build - this will generate the index.html and the other static assets. You can use this option if you already have a local web server set up.
npm run preview - this will generate a production build and run it using the built-in dev server, by default at http://localhost:5000.

The second option is clearly more straightforward and so let’s just run the preview command and see what happens:

$ npm run preview

> vue-bookstore@0.0.0 preview /Users/andrei/workspace/vue-bookstore
> vite preview

  > Local: http://localhost:5000/
  > Network: use `--host` to expose

Writing the Test Script

Now that we have a production-ready build running, we can start writing the actual test in test/e2e/homePageTest.js. We’ll start small, with just the below:

describe('Homepage End-to-end Test', () => {

  it('tests if homepage is loaded', browser => {
    browser
      .navigateTo('http://localhost:3000')
      .assert.visible('#app .new-arrivals-panel')
      .expect.elements('#app .new-arrivals-panel .col-md-6').count.toEqual(4)
  });

  it('adds 2 volumes of "Rhinoceros and Other Plays" to cart', browser => {
    browser
      .click('.new-arrivals-panel .col-md-6:nth-child(2) button.add-to-cart')
      .click('.new-arrivals-panel .col-md-6:nth-child(2) button.add-to-cart')
      .assert.textEquals('.shopping-cart .badge', '2');
  });

  after(browser => browser.end());
});

The test verifies if the New Arrivals panel is displayed in the page and that it contains all 4 entries which we’ve already seen.

Running the Test Script in Chrome

To run this in Chrome, the command is very similar to the one for the component test:

npx nightwatch test/e2e/homePageTest.js --env chrome

And the output will be:

[Homepage End-to-end Test] Test Suite
──────────────────────────────────────────────────────────────
ℹ Connected to ChromeDriver on port 9515 (2454ms).
  Using: chrome (97.0.4692.99) on MAC OS X.


  Running tests the homepage:
──────────────────────────────────────────────────────────────
  ✔ Testing if element <#app .new-arrivals-panel> is visible (157ms)
  ✔ Expected elements <#app .new-arrivals-panel .col-md-6> count to equal: "4" (18ms)

OK. 2 assertions passed. (765ms)

Running the Test Script in Firefox

If we’d want to also run our end-to-end tests in the Firefox browser, we only need to install the GeckoDriver (the Firefox specific implementation of the W3C WebDriver API). No other config is necessary to get it working, unless you’s like to customise it further.

So let’s go ahead and install it from NPM:

npm i geckodriver --save-dev

And then run Nightwatch with the following command:

npx nightwatch test/e2e/homePageTest.js --env firefox

And the output:


[Homepage End-to-end Test] Test Suite
──────────────────────────────────────────────────────────────
ℹ Connected to GeckoDriver on port 4444 (1737ms).
  Using: firefox (96.0.2) on MAC (20.6.0).


  Running tests the homepage:
──────────────────────────────────────────────────────────────
  ✔ Testing if element <#app .new-arrivals-panel> is visible (54ms)
  ✔ Expected elements <#app .new-arrivals-panel .col-md-6> count to equal: "4" (6ms)

OK. 2 assertions passed. (612ms)

Running the Test Script in Safari

If you’re using a Mac, then safaridriver is probably already installed, depending on your Safari version.

You can check with using:

safaridriver --help

And the output should look like:

Usage: safaridriver [options]
    -h, --help                Prints out this usage information.
    --version                 Prints out version information and exits.
    -p, --port                Port number the driver should use. If the server is already running, the port cannot be changed. If port 0 is specified, a default port will be used.
    --enable                  Applies configuration changes so that subsequent WebDriver                           sessions will run without further authentication.
    --diagnose                Causes safaridriver to log diagnostic information for all sessions hosted by this instance. See the safaridriver(1) man page for more details about diagnostic logging.

Before running your first test in Safari, you just need to enable automation, with the following command:

safaridriver --enable

And then simply run the Nightwatch test with:

npx nightwatch test/e2e/homePageTest.js --env safari

Running in Parallel in Multiple Browsers

If you need to run your Nightwatch tests (either component or end-to-end) in more than one browser, you can also do so in more then one browser in parallel.

Simply pass the browsers as a comma separated list (no spaces:

Running in Firefox+Chrome

 npx nightwatch test/e2e/homePageTest.js --env firefox,chrome

Running in Firefox+Chrome+Safari

 npx nightwatch test/e2e/homePageTest.js --env firefox,chrome,safari

Nightwatch also supports running tests in parallel by dividing the total number of test script files over a configurable number of workers. But since we only have one file for now, we’ll skip this part. More on parallelism on the Nightwatch docs website.

Step 5 – Enabling Continuous Integration with Github Actions

It looks like it’s time to wrap things up and put everything together. Before we can enable continuous deployment in Github Actions, we need to create the test NPM task.

Creating the “npm test” Task

Now we have both component testing and end-to-end testing in our example project. Of course, it is only at a minimum level so it doesn’t cover everything, but it’s a good start I would say.

The easiest way to tell Nightwatch to run all the tests inside the test folder is to pass the folder as the second CLI argument. We’ll add that as a new NPM task called test so let’s edit the package.json and add the following, inside the “scripts” dictionary:

{
  "test": "nightwatch ./test"
}

We can run the NPM task and pass Nightwatch related CLI arguments like so:

npm test -- --env chrome --headless

We’ll use --headless mode in order to run the tests in Github Actions.

Adding the Github Action workflow

Finally we can add the Github Actions workflow so that our tests can run on every push and every pull request.

Doing so it’s quite straightforward. We’ll use the Node.js template and add a few new steps in the list, for:

starting the dev server in background
building the project and starting the dev server in preview mode, also in background
running both component and end-to-end tests in Chrome, in headless mode

Creating the Github Actions workflow means to add a new file called node.js.yml in the .github/workflows folder which should look like below. Most of this is auto-generated when you navigate to the Actions section from your Github project and choose the Node.js template.

name: Node.js CI

on:
  push:
    branches: [ main ]

  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x, 14.x]
    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}

      - run: npm ci

      - name: Start vite dev server
        run: npm run dev &

      - name: Build the app
        run: npm run build

      - name: Start vite dev server in preview
        run: npm run preview &

      - name: Run Nightwatch tests
        run: npm test

And that's it. A new build will run for each new git push or whenever a new pull request is sent. The build will be ran in 2 separate environments, one for Node 12 and the other Node 14, as defined in the workflow definition.

Where to Go From Here

The project is available on Github at https://github.com/beatfactor/middlemarch and all the code covered here and a bit more styling and imagery. It also contains the code for the shopping cart and a mock checkout page.

You can get it running on your local machine with the usual steps:

git clone https://github.com/beatfactor/middlemarch
npm install
npm run dev

Feel free to send pull requests or report issues.

Getting Support

Vue3, Vite, and Pinia**

The Vue.js core team provides community support for Vue3, Vite, and Pinia on the following channels:

VueLand chat server on Discord
Vue Forum
Vite Discussions on Github
Pinia Discussions on Github

Nightwatch.js

For support with everything Nightwatch testing related, we have the following channels:

Github Discussions
Nightwatch.js chat server on Discord

A Look at End-to-end Testing in Nightwatch v2.0

Andrei Rusu — Mon, 28 Jun 2021 10:31:21 +0000

Background

Nightwatch was published at the beginning of 2014 and was created as a complete and integrated framework which would enable engineers to write end-to-end tests quickly and without headaches. While writing it, we were guided by the belief that writing and running automated UI tests should be a straightforward and pleasant task, and should require as little configuration and maintenance as possible.

The task of interacting with browser internals was already handled by the Selenium project and working with the Selenium server via an HTTP based api was a straightforward task. And so Nightwatch was born by bringing together various existing tools and techniques into one easy-to-use integrated solution.

Seven years later, the open-source testing space for Node.js looks quite different. Several new frameworks appeared over the past few years, each of which is bringing their own set of capabilities to the table and their own interpretation over how automated testing should be done.

Meanwhile, the Selenium json-wire protocol has transition into the W3C Webdriver standard which is now implemented by all major browsers. As far as Nightwatch is concerned, the strategy hasn’t changed that much. In fact, I personally am even more confident to say that, as an open-source project, Nightwatch has now entered the next major phase in its development and maturity.

The strategy for Nightwatch still remains that we should build the solution using tried-and-tested existing tools and techniques in the automation space instead of going our separate way. The Selenium project (which also includes Webdriver) has been around for more than a decade and has consistently refined and evolved how browser automation works, both on local development environments but also at scale, on large distributed cloud infrastructures. That’s why working in collaboration with the Selenium ecosystem makes me confident to say that Nightwatch will not only deliver on its promises but will even surpass expectations.

Nightcloud.io

Another important update perhaps is that we have stopped developing our own cloud testing platform – Nightcloud.io. We were supposed to launch an initial public beta last year, but we've pulled the plug on it I'm afraid. This is due to various reasons, but the main one I suppose is that we – the team at Pineview.io – didn't see enough demand for it to justify the investment. We decided to focus on Nightwatch alone and try and make it the most sophisticated and user-friendly open-source testing framework out there.

Nightwatch V2

Which brings me to the most exciting part of this article I believe. Work is already under way for the next major update – Nightwatch v2, which should land in the public NPM channel by this fall. An alpha version will be available this August.

We are completely reworking the transport layer to use the official Selenium Webdriver bindings for Node.js, which means more seamless browser integration, better and more reliable DOM element handling, and overall more stable and faster tests. Nightwatch v1.x will still be supported and we’ll issue regular patch updates for critical issues. We’ll also try to make the upgrade from Nightwatch v1.5 or higher to v2 as smooth as possible and we’ll try to not introduce any major breaking changes.

Here’s some of the new features in v2 which you might find attractive:

• Support for Actions API

The Actions api provides a more reliable method for generating complex user gestures and will be a built-in feature in Nightwatch (via the existing .perform() command).

• Expanded automatic command retries

In the current version, Nightwatch only supports retrying failed element retrieval operations, but in v2 it will also retry failed element commands (such as when click encounters errors like element click intercepted).

• New relative element locators

The new Selenium 4 relative locators will be available by default in Nightwatch as well as improved existing locators via the Selenium By() api.

• Built-in support for working with file uploads

Currently uploading files with Nightwatch can be cumbersome, but in v2 we’ll add a built-in command which works with the FileDetector api.

• Support for extended Capabilities objects

The primary way of defining capabilities will still be as part of the nightwatch.conf.js config file, but in v2, all capabilities objects created with the Selenium Capabilities api will be also be supported by default.

• Setting network conditions in Chrome

Manipulating network conditions is a regularly needed feature when working with browser automation and we’ll be able to support it in v2 for Chrome and Edge initially.

• Support for working with Devtools Protocol

The Chrome DevTools Protocol allows for tools to instrument, inspect, debug and profile Chromium-based browsers, such as Chrome and Edge, and we’ll add this capability in Nightwatch v2.

• Ready for Webdriver BiDi

The new BiDirectional WebDriver Protocol is by far one of the most exciting recent developments in the Selenium project and it likely to deliver improvements in speed and stability that far outweigh expectations. As soon as it is available, it will become part of Nightwatch as well. You can follow the development on the Selenium website.

• Various new command APIs

Nightwatch v2 will also bring a new .ensure assert api which will mirror the Selenium until apis, global element(), expect(), by(), and browser objects which will enhance the experience of writing tests and provide more flexibility.

• Test runner improvements

Nightwatch v2 will also bring some improvements to the test runner, like ability to re-run only failed tests and improved support for parallel test execution.

The list above is not exhaustive and it might change until the initial public release of version 2. You can also review the updates published in Nightwatch v1.7 in case you may have missed anything.

Tell Us Your Opinion

We are also considering other new features, APIs, and integration with other tools like Appium or Playwright. It would be very helpful if you’d take the time to fill in this short survey and tell us about features you are using or would like to see in the new version. Please do share it with your team.

Thanks for reading. Please make sure to star the project on Github and also to follow us on Twitter; we're at @nightwatchjs.

The Illusion of Innovation in Web Development

Andrei Rusu — Thu, 06 Aug 2020 21:23:33 +0000

Today I somehow ended up on Google's web.dev platform, which I'm assuming it's rather new. There is of course the possibility that I have been–or still am–living under a rock, when it comes to new web technologies. Something caught my attention–an article about using Service Workers and streams to deliver partial updates to a website:

"The key element of this solution is the usage of streams, which enables incremental creations and updates of data sources."

It's actually using the DEV.to website as a use-case, based on Ben Halpern's article here on DEV, from last year. In his piece, Ben is enthusiastically praising the "magic" of service workers to deliver on saving “terabytes of data” in network transfers. According to him, this approach enables the team at DEV to “ship many fewer bytes while also controlling the user experience with more precision.” To see the results–which are indeed very impressive–you only have to reload the page to his article, or this very article for that matter.

This architecture is known as the App Shell Model and it seems to be growing in popularity lately. It might in fact be the most innovative development in frontend web space since the dawn of AJAX and JSON. The basic idea is to deliver only a very minimal page structure in the initial request and then gradually deliver the rest via fragments or partials, while leveraging caching. So is this the most paradigm shifting web architecture since a decade ago? It does certainly have the potential. I'm a little skeptical regarding the use of the term "magic” though, as is the case in Ben Halpern’s article.

On Magic

Magic is not innovation, it's the opposite of it. Without getting too much into the metaphysics or the occult, I think we can agree that traditional magic works by creating illusions. And just in case we do want to get into metaphysics, even if for a little bit, there's a great 2003 Ted talk by philosopher and cognitive scientist Dan Dennett, called "The illusion of consciousness", which he starts by humorously explaining the difference between magic and real magic (spoiler: there isn't one):

"Real magic, in other words, refers to the magic that is not real, while the magic that it is real, that can actually be done, is not real magic."

Confused? I know I am. But don't worry, it's only because consciousness itself, or the mind, the self, however you want to call it, "is a bag of tricks", according to Dennett. In other words, it's an illusion. When something is truthful it's only because it appears to be so to our consciousness, and however truthful something appears to us depends on how convinced we feel about it.

But enough about magic. Let's not ruin it, shall we? Let's keep the magic alive. Back to service workers. My main concern is that saying it's "magic" will make it difficult for this technology to be properly understood. A certain technological breakthrough can be an actual innovation only if it's widely adopted. And for service workers to become widely adopted, they have to be properly understood by everybody, not just the most advanced and experienced engineers.

Slickness is Tedious

I remember being first introduced to AJAX (Asynchronous JavaScript And XML) in 2006 and even as I was a junior developer (by experience) I recall having clearly understood what it does–updating the page by doing HTTP calls in the background, without reloading the page. We call this a single-page application nowadays (or SPA–not an acronym which I'm very fond of, personally). And thinking at the past decade, I can't say that I'm convinced of anything being a major innovation in how websites and web applications are built and how they work.

There are of course several high profile Javascript frameworks, the language itself has been tremendously improved in terms of readability and maintenance, and several new html5 apis have been added, but to me it seems that the actual web UI looks pretty much the same as it did in the jQuery days, by which I mean about a decade ago. And if there are any actual innovations, those are mainly the domain of aesthetics, i.e. graphical design, such as SVG or WebFonts, and not performance or interaction.

While the aesthetics may or may not be important, as the visual impact can vary from one person to another, the performance impact is certainly the most important one to consider. When measuring the visual impact, there's a certain threshold above which the user interface becomes stable and subsequent updates are more or less redundant. There's a certain point where the application is slick enough and any amount of additional slickness is irrelevant, and it might even be tedious.

On the other hand, a performance update that can "magically" make the app load much master can have a dramatic effect for everyone who's using it. Improvements in performance can have near universal benefits, because it saves us time–we spend less time while waiting for an event to happen in the application (such as a page or an image to load). A performance benefit is like time regained, because the way time is perceived by our consciousness is shared across all of us, presumably.

Service worker diagram from Beyond SPAs: alternative architectures for your PWA

Not Another Bag of Tricks

The “App Shell Model” architecture, as Ben Halpern has shown, sure seems to be the innovation which delivers on the performance gain. But the technology to implement it has been existing for a good while. As Ben also points out, streams have been around as long as the web itself, and also a server-push mechanism has been available in all major browsers for longer than a decade ago, namely the EventSource API, or server sent events. I have myself done a presentation about it just seven years ago.

In fact, the initial content-type of the events being sent through this API was application/x-dom-event-stream and have been later changed into the more generic text/event-stream type, according to this, so presumably the EventSource API has been designed for this purpose, as a mechanism which would accommodate streaming updates to the DOM from the server. Bearing in mind also that document fragments have also been existing since the dawn of time, you got yourself a complete server-push-to-dom-fragment architecture.

These days however, what counts as innovation is mostly determined by the big tech “innovators” in Silicon Valley and the innovation itself is usually permitted to happen only if it furthers an agenda of economic growth and corporate prosperity. Even if it does happen on the outside of the big tech corporations–and remember that the world needs massive corporations just as it needs small businesses, as Zuckerberg recently pointed out–the innovation is absorbed and marketed properly to maximise the potential of value delivery. But what does it matter, innovation is innovation regardless of where it comes from, when it does make it. Whether this particular innovation–the “App Shell Model” architecture (we might want to do something about this naming)–is the next AJAX remains to be determined, of course. Personally, I am quite enthusiastic at the prospect of yet again having an actual innovation in website and application building and not just another bag of tricks.

--
Main photo by moren hsu on Unsplash

Digital Ecology

Andrei Rusu — Sat, 18 Jan 2020 00:00:00 +0000

Photo by Pop & Zebra on Unsplash

"The end is in the beginning and yet you go on." — Samuel Beckett

Almost exactly one year ago I found myself sitting in a meeting room together with four gentlemen. I was interviewing for a scientific programmer job at a small software consultancy, at that time located somewhere outside Oslo. It was a pleasant sort of affair, though at one specific point during the discussion, the atmosphere in the room took an expected turn.

"He’s one of those environmentalists" — the CEO was probably thinking, by the curious expression on his face and slight change of tone in his speech. His attitude appeared to become more defensive and he also seemed surprised that I’d be preoccupied with matters concerning the climate. After all, this is a sought-after software engineer position where one would be working with several cloud technologies, in a team of geo-physicists and data scientists. And the company was also a spin-off of a reputable software research institute in Norway.

The advertisement said the company is developing solutions for the energy sector. I don’t know exactly why, but I assumed “renewable” energy. But the story that was presented to me during the interview was slightly different from what I imagined. I’ve been presented with a sophisticated desktop application which was used in the development of seismic modelling of the ocean floor, for the purpose of discovering and exploration of oil reserves. One of the main customers was the biggest Norwegian producer of oil & gas, Equinor.

“But the world is transitioning to renewable energy sources,’’ I said after they finished the presentation, with what must have been an unexpected interruption. And even if the atmosphere has started to become considerably awkward, I kept on and, addressing the whole group, I asked if they had seen the latest IPCC report on global warming. At that time, the CEO didn’t seem familiar with the report, but one of the scientists was and mentioned something to him. Eventually the CEO made a remark saying that of course they agreed with the need to transition to renewable energy sources but that needs to be addressed from an economic point of view as well. The rest of the group didn’t seem to disagree with the narrative.

Equinor has published last year a press release celebrating Norway’s third largest oil field beginning production, and branding it “a technological triumph and a milestone for the Norwegian oil industry”.

They also seem to acknowledge the severity of the climate crisis and the importance of cutting down on emissions. “It’s 2019 and climate strikes are taking place the world over. So why are we so proud of our new oil field?”, says on the promotional page of their newly opened oil field.

Why indeed. Equinor is no doubt trying to have their cake and eat it, as they say in Britain. They are reassuring shareholders and doing everything in their capacity to appear supportive of the Paris accord, while still producing more oil.

The Age of Perpetual Crisis

“I can feel the discomfort in your seat”, the lyrics of a popular song goes. 2019 was a year when the climate crisis has reached the forefront of the public imagination, and any stories about it now carry a significantly higher degree of discomfort. Headlines are telling us, in a rather alarmed tone, that we are living in the age of perpetual crisis — environmental, social, political. “It’s a Jungle out there”, as another popular tune would say.

I’ve considered writing something on climate from a practical point of view, to examine how the tech industry might be able to contribute with direct solutions. Such an article would probably have been something like a call to action — let’s get enough people interested, raise awareness of the environmental crisis, and then start working on cleantech solutions. If we can deploy some capital on green start-up accelerators, maybe we can make a significant contribution to solving the biggest crisis that humanity is facing at the moment. And hopefully someone will turn off the oil pipes.

I did try to write such a piece. I started collecting stories related to climate and the environment from the tech industry. Noticeably, there aren’t so many such stories. In the tech industry, the collective preoccupation with climate change or the environment is still severely limited. Anything that has to do with the climate or the natural world appears merely as an after-thought, and gets dismissed almost instantly as something which happens somewhere else.

As my research was expanding, my discomfort was mounting. My original idea to write a piece on climate from a software developer point of view looked increasingly like a superfluous and banal enterprise. I’ve come to the conclusion that initiatives like carbon-neutral data centers have ultimately the effect of a drop in a bucket, compared to what the response to the climate crisis should be. Instead I decided to investigate why is there such an enormous lack of urgency and disconnect between where the tech industry is at the moment and where it should collectively be, and if it is even conceivable for the tech industry to be focused on solutions for the climate crisis?

Speaking of collective action, the open source funding platform OpenCollective recently published an article on their blog in which they have sounded the alarm regarding our current predicament and they have announced their participation in the Global Digital Climate Strike, urging others to do the same. The movement was initiated by the international climate campaign group 350.org. The action consists of temporarily shutting down your website or service, in part or completely, in protest against the lack of policies to tackle the climate crisis. 350.org is also behind the global climate strikes and is backing Greta Thunberg’s Fridays For Future school strikes movement, which have proved the most effective and galvanizing climate movements in recent years, if not decades.

Climate Change Can’t Be Solved With Enthusiasm

Alright, but why is this our problem? We’re in the software development business, and our primary concern is to build and ship software. How is this our responsibility? Insisting on this argument makes the entire tech industry look like the musicians on board of the sinking Titanic ship, playing to the tune of the inevitability of their peril. But the tech industry, being mainly concerned at the moment with things like AI, ML, Blockchain, or crypto currencies, hasn’t even realised the terrifying course we are on as a planet.

Instead, it is perfectly in tune with the neoliberal economic model which demands exponential growth through free-market capitalism, without the slightest concern for the climate and the effects that digital technology has on the environment. Even more so, when it comes to technologies like Blockchain, everyone is in love with its potential to deliver on the libertarian dream of decentralisation and democratization of institutions, with even the UN endorsing it, and for climate action no less.

Photo by Marija Zarik on Unsplash

Still, one tech founder tells me on Twitter that there is “growing concern” in the tech industry, which might suggest there is some hope that maybe climate change and the environment will stop being the annoying buzz-killers in the background.

“Climate change is the new crypto”, another tech investor wrote on Twitter last November, suggesting that many of the “smartest minds in tech” are shifting their enthusiasm to working on solutions for the climate crisis. The appetite for working on climate solutions in the tech industry does appear to be growing at the moment, although no major government seems capable of entertaining the idea that fossil fuels must stay in the ground.

Okay, so isn’t this good news, that there is some preoccupation in the tech industry? Not necessarily, no. For one, almost all efforts in the tech world seems to focus on legitimising its operations, either digital or logistical, by cleaning out its act, for instance with Google’s carbon neutral data centers. In the specific crypto sphere, there are also detailed reports, such as this one, which goes to great lengths to claim that the crypto mining operations use around 85% renewable energy.

Climate change is not an issue to be solved with enthusiasm. You can’t simply fix global warming by launching green start-up accelerators and investing in “disruptive” new technologies to lower emissions, despite what Bill Gates would have you believe. It’s not enough to make our applications greener and our data centers carbon neutral and then carry on with business as usual. Such initiatives not only have little to no actual effect, but they may obscure the reality, potentially giving the impression that things are going well and action is being done. And the harsh reality is that the tech industry still works hand-in-hand with the already heavily subsidised fossil fuel industry in enthusiastically supplying digital technology and infrastructure, such as cloud data platforms.

For execs of big tech companies, taking a strong position in fighting the climate crisis is nothing more than a ridiculous fantasy. To Amazon, for instance, the idea that they should take any meaningful action sounds so obscene that they have to resort to coercive measures against their employees who organize and demand it. Amazon isn’t the only major tech company facing calls for stronger climate action.

Google is also facing mounting pressure, with more than 2,000 employees having signed a pledge supporting climate action and a separate open letter which calls on the tech giant to commit to and release a company-wide climate plan. There is also an industry wide tech workers coalition, albeit only in its infancy, but acknowledging “tech’s dirty role in climate change” and voicing bold demands. In addition, there is a global community ClimateAction.tech where tech professionals can connect with one another on matters concerning climate change.

Responsibility Is Not Predicated By Guilt

Perhaps one aspect can offer the best explanation to why individuals are being reluctant to demand stronger climate action. It is quite uncontroversial to say that people all over the world are responsible for global warming. If only we could have done a bit more recycling, if only we would have changed the petrol engine car to a Tesla, maybe we wouldn’t have ended up in this mess.

“Anyone can make a change”, isn’t this what we’re told? Sure, anyone has the power to turn off the oil pipes. Each of us sits on the board of multinational corporations and can decide how much rainforest is going to be wiped out to grow palm oil so we can enjoy a chocolate spread for breakfast. Don’t we all have millions to spend on financing think-tanks so we can lobby policy makers? Yes, anyone can make a real change.

Photo by OneSave/Day on Unsplash

As I write this, Australia is battered by the most severe wildfires ever witnessed in its history, and take for instance Richard Flanagan’s December column for The Guardian, who’s one of Australia’s most prominent novelists and also an outspoken environmental campaigner. Referring to the climate crisis, he makes the statement that “human beings all over the world are responsible [for causing it]”. This is a fundamental problem in the way in which we talk about the climate crisis. Humans as a species have caused global warming, but you personally did not cause it, even if you read this article on an iPhone.

Nor had I caused global warming, just because I am writing this on a laptop. Individuals aren’t guilty for mass extinction, which is what global warming leads to, but guilt is being scaled down to individuals. We are however, as a species, as a whole, responsible to fix it, but responsibility is not predicated by guilt.

Being Ecological In The Anthropocene

As an individual, you can’t do anything to stop climate change, however you may be prepared to change. We need a radical new attitude to the climate crisis, ecology, and the environment, which should begin with not worrying about our own individual carbon footprint. In the current free-market, global economic system any individual efforts of minimising it are practically worthless.

In addition, our current anthropocentric attitude towards ecology, especially in the tech world, is incompatible with any kind of effective climate action. The theorist Timothy Morton, who’s been dubbed “the philosopher prophet of the Anthropocene” by The Guardian, makes the case that thinking in an ecological way requires that we let go of our current idea of nature. In his last book Being Ecological, Morton, who adheres to a school of philosophical thought known as Object Oriented Ontology (OOO), argues that our pastoral view of nature, our association of it with rolling hills, green meadows, birdsong, and so on, are very problematic and may even prevent us from contemplating any effective action.

According to Timothy Morton, nature isn’t “actual trees and bunny rabbits, it’s a concept, an interpretation”.

Being ecological doesn’t mean that we must become aware of the environment and the natural world, it means that we discard the idea that there is a separation in the first place. There is no separation between an iPhone and a bunny rabbit, or a slug for that matter. Everything is interconnected, and it’s not the bunny rabbits that are causing mass extinction. They can’t turn off the oil pipes by themselves. If you read this and think that it sounds ludicrous, consider that for thousands of years this ecological way of co-existence with the environment, known as kincentric ecology has been common to most indigenous peoples around the world. Something which the modern Eurocentric idea of progress through industrial capitalism has instructed us to dismiss in an instant.

It is for all accounts and purposes unrealistic to expect strong action on climate from big tech companies, who will most likely take any ecological idea and laugh it out as preposterous hippie-dippie nonsense. However tech workers are very far from having explored all avenues that could lead to collective, effective action, especially when you consider the fact that most of the software which powers the world’s digital infrastructure is by now open-source. Climate strikes, along with action by the activist group Extinction Rebellion, have been proven the most effective and galvanising forms of climate action in the past year. Indeed, as Oscar Wilde wrote in 1891, “it is through disobedience that progress has been made, through disobedience and through rebellion.”

Originally published at https://hackernoon.com on January 18, 2020.

I am not a Hacker

Andrei Rusu — Tue, 04 Jun 2019 14:23:23 +0000

The term hacker seems to be enjoying great popularity, with websites like HackerNews, HackerNoon, HackerRank, recruiting events like HackerX or the all-too-familiar and ever prevalent "hackathons". It's a hacking bonanza.

I have never referred to myself a hacker and every time a go to a HackerX event or a hackathon I feel uncomfortable and out of place.

When are we going to be past this hacking tomfoolery, hacking "culture", hackers, hackathons?

Music for coding – what do you listen to?

Andrei Rusu — Wed, 29 May 2019 11:31:33 +0000

I'm almost always listening to music while I am coding, and especially when I am at home, where I don’t need to wear my headphones. I listen to a lot of different music and usually try to listen to new music as well, something that it’s unfamiliar or that I haven’t heard before.

Some studies show that listening to music while working "can make us more productive". However, this study, suggests that listening to music may "disrupt creative performance in insight problem solving".

If I am working at home I can't stand being in a quiet room, so I need to listen to music. If I'm in an office I usually listen to something on my headphones, but not always. Sometimes I just listen to the noise of the room if it's not too disruptive.

The first instance of background music appeared, as far as I can tell, in France in 1917 when composer Eric Satie coined the term Furniture Music. Not a very flattering term, but I think you will find some of his music, such as the Gymnopédie No. 1, very well suited as background music while working. And this particular composition is almost always found in those several hours long playlists of classical music for concentration and mindful listening that are everywhere on Spotify, Youtube etc., together with Chopin's Nocturnes, Schubert sonatas and the list goes on.

Is Classical Music then best suited for this job? Perhaps. At least, some of it. I think if you listen to, for example Ionisation, a piece written in 1931 by Edgard Varèse, you will find that this might not work very as background music, at least in the same way that Satie’s music does. I'm not even going to mention composers from the Darmstadt School.

Is it music Pop music with vocals then? Or maybe Jazz? Perhaps Electronic dance music? I also find that music with repetitive structures works very well, which is at the core of a current of contemporary classical music known as Minimalism and in this Essay for BBC Radio 3 New York based novelist Hermione Hoby reveals how she always listens to Steve Reich's Music For 18 Musicians while writing.

This might sound somewhat pretentious, but isn't writing code also some form of writing? We are all creators with stories to tell, are we not? What particular piece of music do you rely on to telling those stories?

--
Cover photo by Corey Silva on Unsplash

The Missing Introduction to Kafka

Andrei Rusu — Thu, 11 Apr 2019 13:21:00 +0000

Photo by Saketh Garuda on Unsplash

I have been fascinated by the open-source Apache Kafka service platform since I first heard about it some years ago. In part for the goal it has set out to achieve — to make microservices talk to each other, but also because of its name.

Why is it named Kafka? This is indeed something I find curious. There is a certain sense of intrigue when a software library or platform goes a bit further than the norm and picks a more unusual name. In this case the name Kafka goes well beyond the trivialities of daily existence and into a surreal literary realm.

I wholeheartedly welcome any sort of connection to anything foreign to software and technology, such as the literary world of Franz Kafka in the case of Apache Kafka. Working as a software engineer for more than a decade, I sometimes begin to look at software and technology as a sort of static, dehumanized space of data and algorithms where nothing much happens and where the banal and the mundane thrives. And I don’t mean dehumanizing in a dystopian technological singularity sort of way with artificial super-intelligence controlling the world. I mean it in a purely modern way, as someone who earns a living in the software space which is often void of human interactions.

According to the Wikipedia entry, the Kafka platform was named after writer Franz Kafka and that was because, being a system optimized for writing, the creators thought it was fitting to use the name of a writer. In addition, Kafka is well resonating name for a software library — short, interestingly sounding, easy to remember. But Kafka also happens to be a well fitting name for a system that operates with message queues and events for more reasons than just Franz Kafka being a writer.

As it happens, he had a peculiar affinity with messages and communication. In 1917, Kafka wrote a short story entitled Message from the Emperor, in which a subject is entrusted with an urgent message at the bedside of a dying emperor. In the piece, which is barely one page long and presented as a parable, the messenger, who is an “indefatigable man” travels tirelessly through crowds, then stairways and courtyards again and again for thousands of years, never reaching its destination.

Messages are also themes in some of Kafka’s other works, such as “In the Penal Colony”, where the message is inscribed on the back of a prisoner by a brutal apparatus or Amerika, which is set in an ultra-modern New York City and where communication is central to the story.

By now you have probably concluded that this particular article will not be diving deep into the workings of the Apache Kafka software platform. If you’re a software engineer and you happen to be reading this while you’re trying to get more familiar with the system, you might see this entire story as some kind of literary poppycock which is completely irrelevant to what you were looking for. If you're a literary oriented person you are probably equally disillusioned, though you will most likely beware to not purchase a ticket to that Kafka Summit.

By now you might feel a bit annoyed and potentially even revolted. Even more so if I tell you that I have never used Apache Kafka. I had used RabbitMQ for some time, which I believe is a competitor platform, but I am not an expert on it. Nor am I an expert in the literary works of Franz Kafka for that matter.

The Essay - In the Shadow of Kafka - Waving or Drowning: Kafka and Meaning - BBC Sounds

On the other hand, Karen Leeder — translator and professor of Modern German Literature at the University of Oxford — is an expert by all accounts and she notes in a 2015 essay for BBC Radio 3 that Kafka did write a lot of letters and he was paranoid with whether the letters will ever reach their destination. Somewhat in contrast with the software platform Apache Kafka which does everything possible in order to send those messages and has elaborate mechanisms to guarantee not only their arrival but also their acknowledgement.

But what would Franz Kafka think about his name being used by a software platform? No doubt, he would find it terribly funny, as he did find his works later in his life. Although not particularly comical, some of them do bear a surreal or absurd aspect that could be seen as amusing. Or maybe he would think the whole matter is kafkaesque. And if you’re still not convinced, consider this last sentence from Message from the Emperor which is suddenly directed at the reader: “You, however, sit at your window and dream of the message when evening comes”.

On Improving Communication Inside a Dev Team

Andrei Rusu — Thu, 21 Mar 2019 21:49:34 +0000

I have been working as a front-end engineer for about 15 years. I have started as a junior PHP developer in my university town of Iași in Romania, and gradually moved further away from home afterwards. Throughout the years I have worked for companies in Bucharest, Nicosia, Amsterdam and, for the past five years, in Oslo.

While in the different jobs I noticed one particular aspect of the job has been more or less consistent - disagreements between developers within the same team. As a developer it's probably quite easy to get into an argument with another team mate. And during the disagreement, all parties involved are very convinced that they are right. They all think that their solution is the best one for everyone involved and they will insist on their path. Usually a compromise will be reached, but they will still believe that their solution was the correct one, even if it wasn't selected by the majority.

But no matter the outcome of the disagreement, the important thing is in my experience how the entire process of settling the dispute is handled by all parties involved. Most of the times, the parties will prefer to keep things between themselves and not involve external mediators, which is of course the ideal situation. When a mediator does intervene, they will only do so in order to make a decision, but the tension in the team will most likely remain.

The team members need to be able to resolve disputes in a civilized and friendly tone as possible, regardless if they feel friendly towards each other or not. This will not only have a positive impact for the rest of the team and organisation, but also for their own morale as employees and members of the team. Throughout the years, and also having participated in a few communication training programs, I have built a small set of techniques, in order to try and have a smooth communication with the other team members. Most of them will sound as common-sense stuff, but here goes:

1. Avoid: "I want"

I hear this a lot from other people in the team - "I want to have this or that because...". And they might give a good reason or explanation, but the problem here is that they put the emphasis on what they want and this might make other people feel uncomfortable.

The important thing to remember is, in my opinion, that even if it's a one person team, in most cases is not about what they want. It is about what is good for the team and the organisation. That does not mean that what the team members want is not important, but when someone says "I want" the other person doesn't usually hear collaboration.

Try this instead:

"I think we should do it this way, because..." or "I am confident that this is the way to go forward..." and so on...

2. Avoid: "You're wrong"

This is maybe even more important one to avoid as it is more effective at damaging your relationship with your colleagues. Or with anyone for that matter.

So this must be avoided at all costs. There is no place for it in a team who has respect as one of its core values. Of course, people are sometimes (oftentimes?) wrong. And if you need to communicate that to them you should do so by using empathy and respect.

Try this instead:

"I'm not sure about that, because..." or "I'm not convinced that's the best way".

Sometimes you may require something stronger, but still respectful and not harmful, although it shouldn't be used lightly: "I disagree". And there are variations, depending of the intended tone and nature: "I respectfully disagree" or "I strongly disagree".

3. Avoid criticizing the work of your team mates

There's a myth existing for a while in development teams, which goes a bit like "you are not your code". That is presumably meant to say that you shouldn't feel too bad when things go wrong as a result of your code changes. But sometimes it is also used as a platform for offering criticism.

Personally, I never found expressions like "constructive criticism" to be useful. In my view, "constructive criticism" is an oxymoron - you can't be constructive if what you're doing is criticizing someone's work (or someone).

Instead of offering criticism, we should be offering improvements.

Try this instead:

"I think we can improve this by doing this or that..." or "I believe this might not work in some/all cases. Here's why..."

4. Dealing with unpleasant situations

Sometimes you may find yourself in an unpleasant situation and usually the best way is to deal with it is to confront your co-worker, if the situation allows, at least as a first step. They might not have meant any harm or they might not realize that their behaviour or remarks were harmful or distasteful.

I have attended a communication seminar some time ago when I was working in Amsterdam. I didn't care too much of it, but the main takeway was quite good advice. They suggested your response when someone did or said something which bothered you in some way should be summarized in three main points:

start by saying what happened, from an objective point of view - or what your impression is;
state how it made you feel - this doesn't need to show any personal emotions necessarily, it can be something like disappointed or confused;
state what you would wish it would happen next - offer some kind of solution to remedy the problem.

Here's an example where one colleague tells you to stop complaining and get on with your work, for instance. You might feel a little put off but hearing that you are complaining, when what you were trying was to highlight a problem that was bothering you. So one response could be:

"I see you're saying that I'm complaining. That is something I normally try to avoid so I'm a bit disappointed by hearing this. I still think it's important that we address this issue and try and find a solution because it is bothering me."

Personally, I don't always feel that confrontational. I wish I would be, but in situations where I think I should have said something and didn't, I always have the option to send them an email. In it I can be as detailed as I want and I can express my opinion uninterrupted and concisely as I see fit.

Sending an email might not sound like the most courageous strategy, but it is of course what Franz Kafka did as well when he attempted to confront his absolutely unimpressive father by sending him the famous letter.

5. Don't hold grudges

This is always great advice, regardless of the situation. And it seems that actor, author and podcaster Russel Brand also has the same advice, and he probably will be more convincing.

Dear [Applicant]

Andrei Rusu — Sat, 16 Mar 2019 12:59:13 +0000

This is an interview rejection letter template to be used as needed by companies. I’ve included a few passages from various rejection letters of my own.

Dear [Applicant’s First Name],

Thank you for completing the interview for the [position name] job with us. After careful evaluation in collaboration with the hiring team, we regret to inform you that we won’t be moving forward with your application, at this time.

As you can imagine, there is a lot of competition for the role and we can only take forward the people we think would be most suitable. While we are convinced that you are perfectly skilled for this position and you appear to have enough academic qualifications, we still somehow feel that you are not the right candidate. You seem like someone who would get in an unpleasant argument with someone from the management team at some point in the future. Surely you understand that we would prefer to avoid these type of situations, it serves no one any good.

We’re also grateful that you took the time and complete our 4+ hours assignment so skilfully that we even got some ideas from it. We would like to encourage you to re-apply for this role in the future, should you still be interested, however please bear in mind that your chances of success will still be limited.

New opportunities arise every day to help us make real what matters. Please don’t let this stop you from applying for a different role, at different company.

We wish you the best of luck with your career, wherever it may take you.

Yours truly,
The Company

Coding Assignments for Job Interviews Are Obsolete

Andrei Rusu — Thu, 21 Feb 2019 23:12:35 +0000

As someone who maintains a relatively popular open-source project on Github for the past 5 years I am becoming increasingly skeptical of companies who ask me to do a coding assignment as part of the interview process. And I do interviews quite often, for one reason or another.

Most companies will ask me to do a coding assignment after the initial phone/skype chat, if successful. Others will send a coding assignment right away after just reviewing the application, even before a phone screening. There are organisations who claim that they are receiving a large amount of applications and so this is a practical solution for them. I’ve got such an assignment following an application for a full-stack developer position at CERN, which evidently was not successful.

However, in my experience, the most common scenario is when I receive the assignment after the phone interview. And the said assignment need not take more than 3 or 4 hours usually. There is even a platform to facilitate this — coderpad.io, a website which aims to provide a live coding environment specifically designed for job interview assignments. Fair enough, the companies need a suitable and effective tool to hire the best candidates they can find, and faster. Right? Wrong.

We don’t need coding assignments anymore. Coding assignments are a thing of the past and in most cases they don’t prove much, as they are quite generic and most of them lack innovation. Even the CERN assignment, of which one would have high expectations, was rather disappointing in terms of creativity. I still failed it though, but that is beside the point.

Now we have a much better tool at our disposal. And it works well for everybody, not just for the companies hungry for talent. It’s the Open-Source community. Instead of the coder doing an assignment which has a high chance of being rejected and thus wasteful, organisations need to simply pick an open-source project on Github and ask the interviewee to submit a pull request for it. Even better, it could be a project that the company uses. Clearly this much more beneficial for the interviewee in the event of an unsuccessful interview as well. In the regular assignment situation, the coder will at best receive a few lines as feedback which is unlikely to be very useful.

Coding assignments are also alienating, stressful, inconclusive. We don’t need that in our lives. Pull requests are useful, empowering, inclusive and transparent. And a platform like Coderpad could work really well here to facilitate things. As a maintainer, I would be very happy to assist them with indicating which Github issues would be most suitable as an assignment.

I recently was in a situation where I have received a 3 hour assignment. This was my response:

Hi {Intervieweer Name},

With respect, 3 hours is quite a long time to ask an interviewee to spend for a coding test. I mean, I have been developing this open-source project for the past 5 years. All the source code is on Github at […] and to be frank I think that is a good indication that I am able to code in Javascript. You can check the source code for {Project}, it has also around 85% test coverage, most of the codebase is written (or reviewed) by me. In addition, you have my CV with presumably enough experience and academic qualifications for this position.

So it is up to you now to decide if you want to move forward with this. Personally, I don’t think it would be very productive for me to spend 3 hours to do a coding test for a job interview when I could very well spend that time fixing some bugs for an open-source project that the community can benefit from. I hope you understand.

Regards,
Andrei

Not a Cultural Fit

Andrei Rusu — Thu, 02 Aug 2018 15:31:48 +0000

About five years ago I was interviewing in Amsterdam for a software engineering position at one of the largest telecom companies in Norway. It was a casual style interview, with two members of the development team, mostly focusing on technical matters, both regarding the position and my professional background. We spoke about one hour and I was left with the impression that the interview went quite well. There were no uncomfortable questions, no long pauses and no gaffes on my side that I could think of. I was quite certain that the process will advance to the next stage.

A few days go by and no sign. I was starting to doubt my overly optimistic evaluation of the situation. Eventually I get an email response from someone at the HR department saying the two interviewers didn’t feel I was a good fit for the position. I was a bit surprised to hear that. By this time I was expecting a rejection, but the feedback left me quite puzzled. So I followed up with an email asking if there’s any chance I get a more detailed explanation on why I was rejected, to which I got the reply that the two developers who interviewed me felt I have good enough technical skills, but they didn’t feel I would be a good cultural fit.

And that’s that. It’s the most dreaded rejection feedback which an introvert like myself, with a healthy amount of insecurity, knows it cannot be challenged or contested. This so-called cultural fit is not something that you can have a say in, or something you can achieve, whether that is something you want to or not. Also it’s not something you can actively train for, like when you’re rejected because “you don’t have enough experience”, or “you don’t have this or that skill”, or even when they need “someone with leadership skills”. If you’re not a cultural fit, that’s rather permanent, and it’s not like you can go out and acquire some and apply for the job next year, mostly because the “culture” is a very loose term in this case and you’re not sure what it is exactly, but you know that you don’t fit in.

Photo by Justin Main on Unsplash

The Company Culture

It is up to the organisation to make the decision if someone is a cultural fit, based on its own values, policies, and other considerations which collectively make up the company culture, although these are not always clearly defined. So in order to be accepted, one must not only have the skills and qualifications required for the position, but also meet the company’s expectations in terms of cultural fitness. How this decision making process works though is not always transparent, one might say even arbitrary. The candidate can be rejected on the basis of cultural unfitness even when they are applying for a position inside a team or department which is currently being formed, and in which case it is unlikely that the culture is well defined.

The company culture varies to a large degree from organisation to organisation, but most of them have one, either explicitly defined or more indirectly shaped. There is a growing trend in the tech industry where the organisation believes that it needs to think it through and decide its own culture. Based on this, the company will review candidates to fill positions, and these candidates will not only have to be qualified but also will need to possess a certain combination of personality traits that are presumed to contribute to the individual fitting in. Some companies will put it forward on its website or blog, others will be more subtle about it towards potential hires. Sometimes the company will discuss its culture with the interviewee as part of the hiring process, in an attempt to make it easier for both parties to decide if there’s a match.

Cultural Fit Recruitment

The culture seems to emerge at a stage when there’s a large enough degree of prosperity and success in the company, often as part of its expansion process. Over the past decade an idea has started to take shape, especially in the tech industry, that companies should attempt to hire for “cultural fit” and many of them seem to believe that culture fit is arguably more important than skills or experience. The argument is that a poor culture fit will lead to higher employee turnover, to speak in business terms, and that can be costly for an organisation, with the Society for Human Resource Management (SHRM) placing this cost in their 2008 Retaining Talent report, and using as reference the “Managing Human Resources: Productivity, Quality of Work Life, Profits” book by Wayne Cascio, at 50%-60% of an employee’s annual salary.

There’s a growing number of articles, many of them from business journals such as Forbes or Harvard Business Review, advocating the practice of hiring for culture fit, such as this one from 2015: Recruiting for Cultural Fit. This type of literature is suggesting that in order for an employee to be successful in an organisation there needs to be a strong match between the organisation’s values, ethics, and beliefs and those of the employee.

The key component of a good “culture fit” can be directly linked to employee happiness, and the idea is that a happy employee is more productive, and that will ultimately lead to more profit. It’s a win-win. Companies believe that fostering the well-being of their employees will contribute to their success, and research by the SHRM shows that promoting policies which will increase employees feelings of well-being, such as respectful treatment at all levels, will ultimately lead to greater happiness levels and overall better job satisfaction. There’s plenty of other sources which indicate that happiness improves business results.

Unsurprisingly though, employee happiness is also determined to a large extent by the individual’s own personality, as research carried out by Robertson Cooper Ltd, a workplace wellbeing consultancy, indicates. They have found that employees who scored high on positive emotions and enthusiasm, and lower on depressive tendencies, will experience more “good days at work” than the others.

If a key component of a successful “culture fit” is personality, then, to a significant degree, specific traits would be those which indicate a relatively happy individual. A less than happy person could not only have problems with adapting and being productive, but also be a negative effect on the rest of the team. Whenever there’s a poor cultural fit, the overall morale of the team is affected, and inevitably is the effectiveness as well. At this point, it’s relatively safe to assume that organisations prefer, for the most part, homogeneity vs eccentricity. For this reason there’s a good amount of effort put by a growing number of organisations into screening candidates for cultural fitness.

A candidate, on the other hand, will attempt to put their best face forward, when interviewing for a new job, or a promotion, in order to maximise the possibility of acquiring the position. This, however, poses a problem of imbalance between people’s behaviour and the emotional states they want to appear they are feeling.

A new study by researchers at Stanford, published in the Emotions journal, found that “what is interpreted as the ‘best impression’ varies from person to person and from culture to culture”. The study further suggests that the practice of recruiting for cultural fit may lead to hiring bias. This finding doesn’t seem to be much of surprise, with various organisations already starting to voice their discontent with the practice, such as Buffer.com, which instead advocates on their Open blog for a slightly different approach called “cultural add”. Facebook also has their own response for managing unconscious bias, an internal training programme which they have made public.

The Nokia Moment

Is the company culture really that important for an organisation success? And if so, how far should the organisation go in terms of applying it? A recent BBC4 documentary called The Rise and Fall of Nokia reveals that in its heyday, a core value of Nokia used to be “Respect for people”. But as Nokia was found itself with huge, unexpected success, a shift in values also started to emerge. The film further shows how Nokia’s enormous, quite sudden, success also started to attract a large number of people who might have been drawn to the organisation just because they were looking for success and financial gain, rather than making a worthwhile contribution. This has overtime led to the core value being reduced to just “Respect” alone, which arguably has played a role in Nokia’s eventual inability to further innovate.

So could this be a case of too much company culture? Successful companies which are now in a position of prosperity, are very weary about their success and how long it might last, fearing a Nokia moment which draws analogies with the moment in which Nokia was just before the release of the iPhone.

I can also report that I may have witnessed a Nokia moment in one of my previous jobs in my career. Back in Amsterdam for about five years I have worked for a start-up which was developing a web and mobile chat messenger platform. A very successful product by all accounts, with a large user base and popularity, reaching its peak sometime in 2009 when profitability was at an all-time high, the engineering team operating as a well-oiled machine, and overall employee job satisfaction was soaring. So the company was expanding and, as a result, the company culture was also being shaped more clearly. The core values and principles were emerging, along with various management level position changes. By 2011, the general attitude has changed, the core companies values were prominently displayed and circulated internally, and these changes seemed to have coincided with a decline in the chat messaging market.

The advent of the iPhone and other smartphones gave birth to a new sort of messaging platform, the most prominent one being WhatsApp, which provided new and exciting capabilities for mobile messaging over traditional chat platforms, such as MSN or Yahoo. My employer was found with a very difficult problem to solve, to adapt to the decline of the market in which they were operating. A new platform was needed, one which will effectively take on WhatsApp, in all its glory. Much like Nokia needed a strong competitor for the iPhone, and just as Nokia came up with the MeeGo platform, they also came up with a competitor for WhatsApp, however it didn’t quite work very well in either cases.

Looking back now, one has to ask oneself if there’s any link between a well-defined company culture and promoting creativity and innovation. Do they play well together? It doesn’t seem to be an idea that André Spicer, a professor at the Cass Business School in London, would agree with, as he writes in his essay published in the Aeon magazine: “Often, these cultures imprison employees in narrow ways of viewing the world, such as the common obsession with constant change”. Spicer has also authored or co-authored a series of books, including The Stupidity Paradox (2016) and Business Bullshit (2018).

The One and The Many

Hiring for culture fit doesn’t seem to play well with diversity and inclusion hiring practices either, which not only make up the recruitment rule of thumb in terms of morality and ethics, but also in terms of legality, at least in democratic countries which have enacted laws for equal opportunity employment. In the US, under the Americans with Disabilities Act (ADA), “employers cannot use eligibility standards or qualifications that unfairly screen out people with disabilities and cannot make speculative assumptions about a person’s ability to do a job based on myths, fears, or stereotypes about employees with disabilities (such as unfounded concerns that hiring people with disabilities would mean increased insurance costs or excessive absenteeism)”. And mental health issues, such as depression, bipolar disorder, post traumatic stress disorder (PTSD), are recognised disabilities under the ADA, and more importantly, are non-obvious during an interview.

This leads to the conclusion that evaluating a person’s happiness levels during an interview and using this type of information to determine if that person is a good fit for the position, based on how they might appear emotionally, is not only immoral, but also possibly illegal, under the ADA. In Britain mental health issues are protected against discrimination under the Equality Act 2010, with mental health conditions that are defined as impairment being listed under Section A of the Guidance document.

Photo by Margo Brodowicz on Unsplash

Could the solution then be to remove the culture component from an organisation recruitment practices entirely? What would that look like? Companies would be left with only qualifications, academic background or experience to judge candidates with. And they would have no choice but to trust that new hires will be a good fit, because if someone doesn’t fit it in a team or a company, there’s probably a reasonable explanation of why that is the case.

Eliminating the culture layer will leave only trust and true diversity & inclusion policies as the baseline, and these should be the only acceptable recruitment practices. This might sound like a concept straight from a utopian novel and well, quite frankly, it is. The world imagined by William Morris in his News from Nowhere (1890) novel is directly associating human happiness with economic activity, and how some of his ideas, not only have practical applications in the 21st century’s “age of the Internet”, as this Aeon.co essay explains, but also how the world seems to have caught up with them.

If recruiting for cultural fit is a practice fraught with problems, then maybe the whole idea of company culture is a failing concept. This might be a classic case of the philosophical problem "The One and The Many" , a concept which was recently debated at length at the 2018 Free Thinking Festival by the BBC.

The quitting economy

One possible take on this problem could result from a concept which is already gaining a lot of attention in the business and economic space at the moment: decentralisation. If one were to apply this to a company and its employees, then the result would probably be the so-called gig economy or the quitting economy. The concept in which these trends originate is based on the ideas put forward by influential Austrian economist Friedrich Hayek (1899-1992) and other members The Mont Pelerin Society, commonly referred to as neoliberalism. This school of thought argues that individual employees, existing or prospective, should think of themselves as businesses, an idea which is analysed at depth by Ilana Gershon, associate professor of anthropology at Indiana University, Bloomington, in her Aeon essay, The quitting economy.

In this kind of environment, which seemingly makes the company culture irrelevant, the emphasis is place on the individual (The One), rather than the organisation (The Many). When an organisation starts to grow and develop its own culture that will later serve as a screening tool for new hires to be accepted, it is also, in many cases, creating a closed circle environment. A type of exclusionary society in which bias thrives, and to which the individual has to adapt in order to be accepted. But in the quitting economy these types of incentives for motivating the employee, who is either an independent contractor, or someone preparing for the next job, are no longer relevant, nor effective.

Gershon further indicates in her essay that the driving force now is passion — how passionate an individual is about their work — and it goes on to suggest that "in the quitting economy, you have to work for passion, and working for passion means focusing on the task, not the company". A manager role is no longer to make sure that an employee is fitting well into the team, but rather to focus on making sure that the employee is able to do their job well, and also to assist them on making the transition to the next job, whenever that might be. Companies now accept that the individual doesn’t really work for the company, they work for themselves and for their passion, and building a career in a company is not something the individual should aspire to.

Even if this thinking might sound a bit too radical for most people to digest, with immediate challenges such as job security and stability, the potentially constant fatigue of having to find a next job, or maybe a lack of feeling that the individual belongs to a group, the initial effect will probably be a shift in the corporate culture narrative, and a transition to a more inclusive and diversified organisational structure.

DEV Community: Andrei Rusu

Test your React Components with Nightwatch and Testing Library

Step 0. Create a new project

Step 1. Install Nightwatch and Testing Library

1.1. Install @nightwatch/testing-library plugin

1.2 Install @nightwatch/apitesting plugin

Step 2. Create the Login component

Step 3. Create the component test

3.1 Login with valid credentials test

Add the mock server

Complete test file

Debugging

3.2 Login with server exception test

4. Run the test

5. Conclusion

Create, Test and Deploy a Single Page App with Vue 3 + Vite and Pinia

Introduction

Step 1 – Setting Up the Application with the create-vite Scaffolding Tool

Step 2 – Adding routing with Vue Router and state management with Pinia

Vue Router

Pinia

Setting Up Routing

What is a Single Page Application?

Working with Vue Components in Vite

Adding Routes

Setting Up State Management Using Pinia

Creating a Pinia

Adding the Catalog Store

Defining the Store

Using the Store in a Template

Step 3 – Testing Vue.js Components

Installing Nightwatch.js and ChromeDriver

Testing the <NewArrivals> Component

Extending the <NewArrivals> Test

Step 4 – End-to-End Testing the Vue.js App

Writing the Homepage End-to-end Test

Running the Production Build

Writing the Test Script

Running the Test Script in Chrome

Running the Test Script in Firefox

Running the Test Script in Safari

Running in Parallel in Multiple Browsers

Running in Firefox+Chrome

Running in Firefox+Chrome+Safari

Step 5 – Enabling Continuous Integration with Github Actions

Creating the “npm test” Task

Adding the Github Action workflow

Where to Go From Here

Getting Support

Vue3, Vite, and Pinia**

Nightwatch.js

A Look at End-to-end Testing in Nightwatch v2.0

Background

Nightcloud.io

Nightwatch V2

• Support for Actions API

• Expanded automatic command retries

• New relative element locators

• Built-in support for working with file uploads

• Support for extended Capabilities objects

• Setting network conditions in Chrome

• Support for working with Devtools Protocol

• Ready for Webdriver BiDi

• Various new command APIs

• Test runner improvements

Tell Us Your Opinion

The Illusion of Innovation in Web Development

On Magic

Slickness is Tedious

Not Another Bag of Tricks

Digital Ecology

The Age of Perpetual Crisis

Climate Change Can’t Be Solved With Enthusiasm

Responsibility Is Not Predicated By Guilt

Being Ecological In The Anthropocene

I am not a Hacker

Music for coding – what do you listen to?

The Missing Introduction to Kafka

On Improving Communication Inside a Dev Team

1. Avoid: "I want"

Step 1 – Setting Up the Application with the `create-vite` Scaffolding Tool