Forem: Kiran Parajuli

Dockerizing Your Django Vue Application: A Step-by-Step Guide

Kiran Parajuli — Sun, 01 Oct 2023 22:49:51 +0000

In this comprehensive guide, we will walk you through the process of dockerizing your Django and Vue applications.

Prerequisites

Docker (version 20.x.x or higher)
Docker-compose (version 2.x.x or higher)
Django application (Django + Gunicorn)
Vue application (Vue + Vite)

Folder Structure

To facilitate this guide, we assume the following folder structure for your project. You can customize it as needed, but remember to adjust the commands accordingly:

.
├── backend (Django application)
│   ├── Dockerfile
├── frontend (vue application)
│   ├── Dockerfile
├── docker-compose.yml

Dockerfile for Django Application

For the Django application, we'll make the following assumptions:

Port to expose: 8000
Serve using: gunicorn
Database: postgres

Gunicorn Configuration

workers = 4
max_requests = 1000
timeout = 30
bind = "0.0.0.0:8000"
preload_app = True
accesslog = "logs/gunicorn_access.log"
errorlog = "logs/gunicorn_error.log"

Note: We use 0.0.0.0 for binding to allow access from outside the container.

Dockerfile for Backend

In this section, we'll prepare the playground for your Django application. We will use Docker Compose to run the application. Here are the assumptions:

Port to expose: 8000
Serve using: Gunicorn
Database: PostgreSQL
Dependencies Listed in: requirements.txt

FROM python:3.10

WORKDIR /app

COPY requirements.txt /app/

RUN pip install --no-cache-dir -r requirements.txt

EXPOSE 8000

CMD ["gunicorn", "backend.wsgi:application", "--config", "gunicorn.py"]

Note: We won't copy all files to the container; instead, we'll use volumes to mount files from Docker Compose to preserve hot-reloading functionality.

Dockerfile for Frontend

Similarly, we'll prepare the playground for your Vue application. We will use Docker Compose to run the application. For Vue, we'll assume:

Port to expose: 3000
Serve using: Vite

To make it work with Docker, add the following to your package.json:

{
    "scripts": {
        "dev:docker": "vite --host"
    }
}

Note: We use vite with the --host flag to make it accessible from outside the container.

FROM node:20-alpine3.17

WORKDIR /app

COPY package.json pnpm-lock.yaml /app/
RUN npm install -g pnpm
RUN pnpm install


EXPOSE 3000

CMD ["pnpm", "dev:docker"]

Just like with the Django application, we won't copy all files to the container, relying on Docker Compose volumes for file mounting to maintain hot-reloading.

Docker compose

Now, let's dive into Docker Compose to run your application.

version: '3.8'

services:
  postgres:
    container_name: db
    image: postgres:16.0-alpine
    restart: always
    environment:
      POSTGRES_USER: einstein
      POSTGRES_PASSWORD: relativity
      POSTGRES_DB: einstein
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: [ "CMD", "pg_isready", "-U", "einstein" ]
      interval: 5s
      timeout: 5s
      retries: 5
    ports:
      - "5433:5432"

  backend:
    container_name: backend
    build:
      context: ./backend
    volumes:
      - ./backend/:/app
      - ./backend/.env.docker:/app/.env
      - ./backend/logs:/app/logs
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - "8000:8000"
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:8000/healthcheck" ]
      interval: 5s
      timeout: 5s
      retries: 5

  frontend:
    container_name: web
    build:
      context: ./frontend
    volumes:
      - ./frontend:/app
      - ./frontend/.env.example:/app/.env
    depends_on:
      backend:
        condition: service_healthy
    ports:
      - "3000:3000"

volumes:
  pgdata:
  media:
  static:

To break it down:

We use depends_on and healthcheck to ensure dependent services are up and running before starting. PostgreSQL is used as the database for the Django application, so we ensure that the postgres service is operational before launching the backend service. A similar approach is used for the frontend service.
Volumes are employed to mount files from the host machine to the container. We mount backend and frontend folders to their respective containers and include the .env.docker file containing environment variables.
Ports are exposed to make container ports accessible from the host machine. In this configuration, we've mapped 8000 and 3000 from the backend and frontend containers, respectively. Additionally, PostgreSQL's port is mapped to 5433 on the host to avoid conflicts.

Running the application

With everything set up, it's time to run your application:

docker compose up

This command will spin up PostgreSQL with the specified database and user. It will also start the backend and frontend services. Access your application at http://localhost:3000.

To run migrations, execute the following command:

docker compose exec backend python manage.py migrate

The choice to run migrations after the application is up allows for easy updates to models without manual migration execution.

To create a superuser, run:

docker compose exec backend python manage.py createsuperuser

Avoid putting superuser creation in the Dockerfile to prevent errors if the superuser already exists.

To collect static files, use this command:

docker compose exec backend python manage.py collectstatic

Conclusion

Congratulations, you've successfully dockerized your Django Vue application! Now, you can deploy it to your preferred cloud provider or use it for the development environment. Happy coding!

Unit testing Vue components

Kiran Parajuli — Fri, 06 May 2022 04:26:46 +0000

This post only covers unit testing information for Vue.js v2 and earlier. If you're trying with VueJS v3, this post would not be helpful.

Why Unit Testing?

When it comes to building reliable applications, tests can play a critical role in an individual or team's ability to build new features, refactor code, fix bugs, and much more.

Unit testing is a software testing technique in which a collection of software components or modules are individually tested.

Benefits:

test individual units of code in complete isolation
maps a system structure and creates documentation. It really helps us understand the unit's interface.
early bug detection and easier to spot issues
saves time with automation and avoids manual testing

Vue Test Utils (VTU)

The VTU is a set of utilities that simplifies testing VueJS components. The package exposes APIs for mounting and interacting with the Vue components independently.

Installation

There are various options for the installation of VTU. Please refer to the official VTU docs for detailed information on how to install and configure VTU.

VueJS projects will already have a bundler set up for the development. So one thing I would suggest for the installation is please do not set up a different compiler or transformer system for the tests and the source code. This will only increase the project complexity and packages dependency. For example: if you're using babel for the source code, use the same for the tests too.

Writing Tests

With VTU, we can write our tests using describe, it, test. Similarly, hooks can be implemented under before, beforeEach, after and afterEach. And, for assertions, expect is also already bundled. Great!

import {mount} from "@vue/test-utils"

// Normally a component to be tested is imported from elsewhere
const FabButton = {
  template: "<button type='button' :disabled='disabled'>{{text}}</button>",
  props: ["disabled", "text"]
}

describe("Fab button component", () => {
  describe("when prop 'disabled' is set to 'disabled'", () => {
    it("should be disabled", () => {
      const wrapper = mount(FabButton, {
        propsData: {
          disabled: "disabled",
          text: "My Button"
        }
      })

      // assertions after loading the component
      expect(wrapper.attributes('type').toBe('button'))
      expect(wrapper.attributes('disabled').toBe('disabled'))
      expect(wrapper.text()).toBe("My Button")
    })
  })
})

Knowing what to test

There can be multiple logic involved in our test files. However, not everything needs to be tested during unit testing.

Don't forget we're only writing tests for a specific component. So we should only test the features provided by that specific unit.

So, is it necessary to test every feature in the component?

For the above component, we have two attributes inside the button element, i.e. type and disabled. We can see that the type attribute is set to the static value button and the disabled attribute is linked with the component prop disabled. So, we can avoid the test for static attributes and only test the computed properties.

it("should be disabled", () => {
  const wrapper = mount(FabButton, {
    propsData: {
      disabled: "disabled",
      text: "My Button"
    }
  })

  // assertions after loading the component
  expect(wrapper.attributes('disabled').toBe('disabled'))
  expect(wrapper.text()).toBe("My Button")
})

Some points to remember:

do not test other components' functionalities otherwise your tests would not be a unit test
do not test functionalities from dependencies of your project
do not test static values as they remain static in any situation
do not focus on complete line-based coverage, as it tends to focus on the internal implementation details of the components, which could lead to brittle tests

`mount` and `shallowMount`

I mostly use shallowMount for unit testing because it does not bother about the other imported or external components used within the component being tested. Additional to that, it does allow us to assert the props provided to those external components. But, if we want to test the component's functionality, we can use mount instead. For example, if we have to click some element inside the component, we can choose mount instead of shallowMount.

Stubs

I try to stub the component when I'm testing as much as possible. For example, if I'm writing a unit test for a component that uses some other component, I can stub that dependency and then test the component.

While working with shallowMount, sometimes I get props or attributes set as [Object][Object]. I cannot parse this to object and further assertions cannot be made. In order to solve this, I use stubs more precisely. Provide the actual component for the stubs rather than just a boolean value.

// Incorrect: this may not always work
shallowMount(Component, {
  stubs: {
    // default stub
    FabButton: true
  }
})

// Correct: stub with the actual component
import { createLocalVue, shallowMount } from '@vue/test-utils'
import FabButton from "@/somelib/component/FabButton"

// if it should be used by vue
localVue.use(FabButton)

shallowMount(Component, {
  localVue,
  stubs: {
    // specific implementation
    'FabButton': FabButton
  }
})

Mocks

Mocks are very useful while unit testing. Our components usually use various methods from other components, mixins, libraries, etc. These are not our responsibility. So, we need to mock them.

Mocking is very easy. We have to remember a few things:

mock before mounting the component
reset or restore mocks after the test
prefer mocking the return values for methods rather than the actual methods themselves

With jest, mocking is done in the following way:

// mocks a module with an auto-mocked version
// 'factory' and 'options' parameters are optional
jest.mock(moduleName, factory, options)
// mock internal private functions
const myMockFn = jest.fn()
  .mockReturnValue(true) // default return value
  .mockReturnValueOnce(1) // return value for first call
  .mockReturnValueOnce(2) // return value for second call

// 'first call', 'second call', 'default', 'default'
console.log(myMockFn(), myMockFn(), myMockFn(), myMockFn());

// mock external library
jest.mock('@nextcloud/axios')
// mock external library methods
jest.mock('lodash', () => ({ 
  ...jest.requireActual('lodash'),
  debounce: fn => { fn.cancel = jest.fn(); return fn } 
}))

Spying

It creates a mock function similar to jest.fn but also records calls to the mock function.

By default, jest.spyOn also calls the spied method. But if we want to overwrite the original function, we can use:

jest.spyOn(object, methodName).mockImplementations(() => customImplementation)

User Interactions

These are well described in the documentation for the vue-test-utils.

Some points I want to mention:

always use await while performing user interactions

  await wrapper.find('button').trigger('click')

always use wrapper.vm to access the component's instance

  expect(wrapper.vm.searchResults).toEqual([])

make sure to use wrapper.vm.$nextTick to wait for async operations to complete if needed

  await wrapper.find('button').trigger('click')
  await wrapper.vm.$nextTick()
  expect(wrapper.find('.content').exists()).toBeTruthy()

make sure to re-query elements whose states are changed after some interactions:

Assume a component with a button which toggles the existence of content in the DOM.

  // Incorrect way:
  const content = wrapper.find('.content')
  await wrapper.find('button').trigger('click')
  expect(fab.exists()).toBeTruthy()

Here the content element is queried before clicking the button. So at this stage, the content is not there. Now even if we click the toggler, the content element will remain unchanged for us. That's why we have to re-query for this element.

  // Correct way:
  const content = wrapper.find('.content')
  expect(content.exists()).toBeFalsy()
  await wrapper.find('button').trigger('click')
  expect(content.exists()).toBeTruthy()

Snapshots

Snapshots are very useful while writing tests. We can use them to check the DOM structure of the component or any other data like objects, arrays, etc.

For example, let's say we have a component like this:

<template>
  <div class="card">
    <div class="title">{{card.title}}</div>
    <div class="subtitle">{{card.subtitle}}</div>
    <div class="author">{{card.author.username}}</div>
    <div class="actions">
      <button class="delete" :disabled="!card.canDelete()">Delete</button>
      <button class="edit" :disabled="!card.canEdit()">Edit</button>
    </div>
  </div>
</template>
<script>
export default {
  props: {
    card: {
      type: Object, 
      required: true
    }
  }
}
</script>

It would be a bit more tedious to find and expect each detail from the component.

it('should render the card correctly', () => {
  // mount the component with the card data
  const title = wrapper.find('.title').text()
  const subtitle = wrapper.find('.subtitle').text()
  const author = wrapper.find('.author').text()
  const deleteButton = wrapper.find('button.delete')
  const editButton = wrapper.find('button.edit')
  expect(title).toEqual('Hello World')
  expect(subtitle).toEqual('This is a subtitle')
  expect(author).toEqual('John Doe')
  expect(deleteButton.attributes().disabled).toBeTruthy()
  expect(editButton.attributes().disabled).toBeFalsy()
})

This is tedious and difficult to maintain. So we can use snapshots to check the whole DOM structure of the component.

it('should render the card correctly', () => {
  // mount the component with the card data
  const card = wrapper.find('.card')
  expect(card).toMatchSnapshot()
})

That's it. All the card data is now checked, and it is much easier to maintain. If something changes in the component, we just need to update the snapshot.

Curious how snapshots are saved and maintained?

When we introduce any test cases that make use of snapshots, at the first time of the test run, the test runner will generate and save the screenshot(s) in a folder __snapshots__ just where the test file is located.

Now, when we run the test again, the test runner compares the saved snapshot with the current DOM structure and fails if the two are different.

To update the current snapshot, we can use the --updateSnapshot flag or just use the jest interactive mode.
jest --updateSnapshot

This is also helpful to assert for large datasets like:

expect(response).toMatchObject([
  {id: 1, name: 'Rose', color: {r: 255, g: 0, b: 0}},
  {id: 2, name: 'Lily', color: {r: 0, g: 255, b: 0}},
  {id: 3, name: 'Sunflower', color: {r: 0, g: 0, b: 255}}
])

can be written as:

expect(response).toMatchSnapshot()

This will save the response object as a snapshot, and our test will look neater. Also, if something changes in the response, we just need to update the snapshot.

Final Thoughts

In a nutshell, unit testing with Vue components with Jest and vue-test-utils is fun. Do not try to get 100% coverage, rather try to test the actual features of the component. The Vue community has good documentation and guides on how to test Vue components. Thus, you're likely to have fewer problems testing your components and securing your path forward.

NightwatchJs and GitHub Actions

Kiran Parajuli — Sat, 19 Jun 2021 16:28:44 +0000

NightwatchJs

Nightwatch.js is an integrated, easy to use End-to-End testing solution for web applications and websites, written in Node.js. It uses the W3C WebDriver API to drive browsers in order to perform commands and assertions on DOM elements.

GitHub Actions

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. You can build, test and deploy your code right from GitHub.

GitHub Actions is available with GitHub Free, GitHub Pro, GitHub Free for organizations, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server, and GitHub AE. GitHub Actions is not available for private repositories owned by accounts using legacy per-repository plans. For more information, see "GitHub's products."

CI using GitHub Actions offers workflows that can build the code in your repository and run your tests. Workflows can run on GitHub-hosted virtual machines, or on machines that you host yourself.

Setup CI/CD

At this point, I assume that you've a working project to test and configure CI for. I'm using this project for demonstration Moving Todo. It is a Django application and tests are written in NightwatchJs.

Now, lets plat our CI configurations:

First, we've to choose an os for CI build
Second, we've to install dependencies inside the build
Next, we've to start server to test
At last, we've to run the tests and make it pass.

Webdriver

Personally I do not suggest using jar files for selenium. Rather use docker to start selenium as:

docker run --rm -d --network="host" --name selenium -p4444:4444 selenium/standalone-chrome

Alternatively, you don't have to bother anything about starting and stopping selenium server. Using npm package manages all of that.

Have the following packages in your packages.json file:

  "dependencies": {
    "@cucumber/cucumber": "^7.3.0",
    "axios": "^0.21.1",
    "chromedriver": "^91.0.0",
    "cucumber": ">=6.0.5",
    "cucumber-pretty": "^6.0.0",
    "geckodriver": "^2.0.0",
    "iedriver": "^3.150.1",
    "nightwatch": "^1.3.4",
    "nightwatch-api": "^3.0.1",
    "selenium-server": "^3.141.59"
  },

Configure nightwatch:

module.exports = {
  src_folders: ["tests"],
  // custom_commands_path: ["test/custom_commands"],
  page_objects_path: "./tests/acceptance/pageObjects",

  test_settings: {
    default: {
      launch_url: process.env.BASE_URL,
    },
    selenium: {
      selenium: {
        start_process: true,
        server_path: require("selenium-server").path,
        port: 4444,
        cli_args: {
          "webdriver.gecko.driver": require("geckodriver").path,
          "webdriver.chrome.driver": require("chromedriver").path,
        },
      },
      webdriver: {
        start_process: false,
      },
    },

    chrome: {
      extends: "selenium",
      desiredCapabilities: {
        browserName: "chrome",
        chromeOptions: {
          args: ["--headless", "--no-sandbox", "--disable-gpu"],
          w3c: false,
        },
      },
    },

    firefox: {
      extends: "selenium",
      desiredCapabilities: {
        browserName: "firefox",
        "moz:firefoxOptions": {
          args: ["--headless"],
        },
      },
    },
  },
};

configure cucumber.conf.js

const { setDefaultTimeout, After, Before, BeforeAll, AfterAll } = require("cucumber");
const { createSession, closeSession, startWebDriver, stopWebDriver } = require("nightwatch-api");
const axios = require("axios").default;

setDefaultTimeout(60000);
const availableBrowsers = ["chrome", "firefox"];

const browser = process.env.BROWSER || "chrome";
if (!availableBrowsers.includes(browser)) {
    throw new Error(
    '\nInvalid browser selected.\n' +
    'Available browsers: ' +
    ${availableBrowsers.join(", ")} + '\n'
  );
}

BeforeAll(async () => {
  await startWebDriver({ env: browser });
});

Before(async () => {
  await createSession({ env: browser });
});

After(async () => {
  await closeSession();
});

AfterAll(async () => {
  await stopWebDriver();
});

Assumed that tests files are inside tests directory, Now add script to run tests inside your package.json file:

"scripts": {
  "test:e2e": "cucumber-js --require cucumber.conf.js --require tests/acceptance/stepDefinitions --format node_modules/cucumber-pretty"
}

Setup workflow

First, touch a file inside .github/workflows naming main.yml. GitHub uses this file as configuration file for CI build.

Now as our plan lets setup our CI:

name: CI

on:
  push:
    branches: [master]
  pull_request:
    branches: [master]

  workflow_dispatch:

jobs:
  build:
    name: webUi-${{ matrix.browser }}
    runs-on: ubuntu-latest

    strategy:
      matrix:
        browser: ["chrome", "firefox"]

    steps:
      - uses: actions/checkout@v2

      - name: yarn-install
        run: yarn install

      - name: pip-install
        run: pip install -r requirements.txt

      - name: setup-server
        run: |
          make migrate
          make create-admin
          make serve &

      - name: e2e-test
        env:
          BROWSER: ${{ matrix.browser }}
        run: |
          yarn test:e2e

Check your builds

Push the changes adding the main.yml to your repository and navigate to Actions tab in your repository, you can see the started build.
Inspect it, fix it, its all yours.

What I love about GitHub CI

you can run sudo commands easily
you can easily use docker containers
you can pipeline your tests into multiple parallel builds

Splat Operator in PHP

Kiran Parajuli — Wed, 24 Feb 2021 10:02:48 +0000

...$str is called a splat operator in PHP (other languages, including Ruby.)

This feature allows you to capture a variable number of arguments to a function, combined with "normal" arguments passed in if you like. It's easiest to see with an example:

<?php

function concatenate($transform, ...$strings) {
  $string = '';
  foreach($strings as $piece) {
    $string .= $piece;
  }
  return($transform($string));
}

echo concatenate("strtoupper", "I'm ", 20 + 2, " years", " old.");

Output

I'M 22 YEARS OLD.

Latest feature

After PHP 5.5.x, arrays and traversable objects can be unpacked into argument lists when calling functions by using the ... operator.

<?php
function add($a, $b, $c) {
    return $a + $b + $c;
}

$operators = [2, 3];
echo add(1, ...$operators);
?>

Output

That's cool. 😎

E2E Testing with Cypress -06- Cypress - Gherkin / Parallelization

Kiran Parajuli — Tue, 02 Feb 2021 03:40:56 +0000

In the previous part of the series we have disused how Cypress is so flexible with multiple CI providers, how it manages balanced strategies on parallel runs, and an example of a CircleCi configuration file. As long as tests are written in Cypress file/folder structure, the configuration of parallel tests run is simple as documented. But if you use feature files in your e2e tests, then your a bit unlucky using Cypress.

As I've mentioned in the earlier part of the series, Cypress does not have a cucumber preprocessor by default, and we have to add some tweaks to get tests containing features files running. It's perfectly fine while running our tests on our own machine. We can properly tag, run, and debug our scenarios with different required hooks if necessary. But in CI/CD we do not want to run our tests as we run in our local machine.

According to some cypress users, using Cypress Dashboard along with cucumber preprocessors, they can run over 200 scenarios in 13 minutes. Parallelization is so effective with dashboard service but, it is a PAID service. But do not worry we can achieve it for free.

Parallelization with cucumber-preprocessor and Cypress

Folder Structure
cypress/integration/features/
  |- Login/login.feature
  |- Register/register.feature

Let us assume, we have two features as shown above. Our goal is to run these two features in parallel in our CI/CD. With Cypress Dashboard service our test files are automatically separated into different suites according to their previous run lengths to maintain minimum test run time. Since we're not using any dashboard, so we've to do this by ourselves. Simple!

So the first thing needed is we've to create suites. Where to create? Inside your features directory. Each folder you create can be used as a separate suite for your CI/CD.

Next, we've to configure our CI configuration to give the above suite's life.

I am currently using the GitLab CI/CD service, so here is an example of a config file running the above tests in parallel.

Example `.gitlab-ci.yml`

image: cypress/base:12
stages:
  - automation

# this is the actual suite name that will appear in you CI/CD
Register:
    stage: automation
    script:
      - npm ci
      - $(npm bin)/cypress run "cypress/integration/features/Register/*.feature"

Login:
    stage: automation
    script:
      - npm ci
      - $(npm bin)/cypress run "cypress/integration/features/Login/*.feature"

That's it. You just have to run the features you want in the suite you want.

Now add and push the changes to your repository. You should see two jobs have been started under a pipeline on the CI/CD section of the repository. Check the run from the GitLab jobs section and find out the test result.

Test Results and Debugging

With the Cypress Dashboard service enabled you can get a detailed test run summary (for the whole test run and specific tests) with so much ease. Since we're not using it, Do we get in trouble while troubleshooting? Absolutely False. Your CI/CD runner log is just enough to debug through your tests if it fails.

Here are screenshots of the GitLab CI test runner with Cypress-Gherkin-Parallelization:

Success log sample
Error log sample

E2E Testing with Cypress -05- Trade-offs In Cypress

Kiran Parajuli — Thu, 19 Nov 2020 18:49:23 +0000

Key Differences

Key differences with other testing frameworks

Cypress does not use Selenium
Cypress tests are only written in JavaScript
Cypress is all in one

These architectural improvements unlock the ability to do TDD with full e2e tests. You can develop faster while driving the entire dev process with tests because: you can see your application; you still have access to the developer tools, and changes are reflected in real-time. The end result is that you will have developed more, your code will be better, and it will be completely tested. If you opt for parallelization and automated load balancing will further supercharge your test speeds.

But, there are some serious downsides to these architectural changes.

The following permanent and temporary trade-offs are well discussed in Cypress documentation. Please follow the official documentation for more information. I've just listed out the main point just for an overview.

Permanent trade-offs

Automation Restrictions: Cypress is a specialized tool that does one thing really well: end-to-end testing of web applications while they are under development. You should not use Cypress for things it is not designed for such as: - Indexing the web - Spidering links - Performance testing - Scripting 3rd party sites There are other excellent tools that are optimized for doing each item listed above.
Inside the browser: In case you missed it before - Cypress tests run inside of the browser! It makes it a little bit harder to communicate with the back end - like your server or database. You will not be able to connect or import those server-side libraries or modules directly.
Multiple Tabs: It will never have multi-tabs support.
Multiple browsers open at the same time: You cannot use Cypress to drive two browsers at the same time.
Same Origin: Each test is limited to only visiting domains that are determined to be of the same-origin. What is same-origin? Two URLs have the same origin if the protocol, port(if specified), and host are the same for both. Cypress automatically handles hosts of the same superdomain by injecting `document.domain` into `text/html` pages, so a host of the same super domains considered fine.

Temporary trade-offs

IMO Cypress has a pretty responsive issues section on GitHub. Many issues that are being worked on are:

Lack of a cy.hover() command.
There is no cy.tab() command.
There is not any native or mobile event support.
Testing file uploads is application-specific.
Testing file downloads is application-specific.
Iframe support is somewhat limited but does work.
You cannot use cy.route() on window.fetch.

Problems I faced with my project's tests

Cypress says, the browser XHRs are properly tracked, and we can wait for them too. But it is not true for me. The test-runner does not log about the XHR requests triggered by the browser interaction, and I cannot wait dynamically for some time-consuming requests.

Testing inside iframes? Well, it's gonna bother you. I am working on a project which uses iframes with large contents and takes some time to load properly. Following the documentation and cypress blogs were also not quite helpful. For now, I'm using static wait before diving inside any iframes. If somebody has a better idea, well, please share!
I feel like why we choose Cypress while testing dropdown fields 😂. I find most of the official tips for dropdown testing is with <select>...</select>. But the recent web is mostly based on frameworks like VueJs, ReactJs, etc. which uses a different mechanism to render dropdowns (using classes rather than using select tag). Options are extracted from some API requests and may also have abilities like autocompletion. With these features included the browser elements keeps on changing (some get in, and some are removed out completely). Running tests with such form fields interactions, you'll surely encounter the Element is detached from the DOM error ref. I suggest do-not-get-too-detached blog to handle this type of errors.
Test just terminates when it likes: Only half of the test runs and that particular test is marked as passed by cypress (happens sometimes but can litter test result accuracy)

What's Next 😎?

Cool, we've known some errors that we may encounter while testing with Cypress. Some are permanent and some are temporary. Some can be handled with ninja-techniques 🐱‍💻. So please choose your testing framework according to your project's need. Thank you!

Enough with these testing tips. Now we want tests running on some CI 🔌 and be always verified with our product services ✅. In the next part of the series, we'll see the CI/CD part of e2e testing with Cypress.

Your thoughts, comments, or questions about e2e testing with cypress are always welcome. Happy Coding 🎉

Deploy Static Web Apps with GitHub Pages

Kiran Parajuli — Thu, 19 Nov 2020 17:54:01 +0000

GitHub Pages

You can use GitHub Pages to host a website about yourself, your organization, or your project directly from a GitHub repository. It is a static site hosting service that takes HTML, CSS, and JavaScript files straight from a repository on GitHub, optionally runs the files through a build process and publishes a website. You can see examples of GitHub Pages sites in the GitHub Pages examples collection.

You can host your site on GitHub's github.io domain or your own custom domain. We'll talk about hosting with a custom domain in later parts of this series.

To publish a user site, you must create a repository owned by your user account that's named <username>.github.io. To publish an organization site, you must create a repository owned by an organization that's named <organization>.github.io. Unless you're using a custom domain, user and organization sites are available at

http(s)://<username>.github.io or http(s)://<organization>.github.io.

The source files for a project site are stored in the same repository as their project. Unless you're using a custom domain, project sites are available at

http(s)://<username>.github.io/<repository> or http(s)://<organization>.github.io/<repository>.

Deploy Your Project

Okay, so much theory. Let's publish our project now.

Create a repository

Head over to GitHub and create a new repository named username.github.io, where username is your username (or organization name) on GitHub.

Clone the repository

  git clone https://github.com/username/username.github.io

Hello World

Enter the project folder and add an index.html file:

  cd username.github.io
  echo "Hello World" > index.html

Push it

Add, commit and push your changes:

  git add .
  git commit -m "Initial Commit"
  git push -u origin master

Done

Fire up a browser and go to https://username.github.io.

Hosted directly from your GitHub repository. Just edit, push and your changes are live.

Whats Next?

How cool is this? A complete web hosting just in seconds and for completely free. 💵🙌💸

In the next part of the series, I'll show you how to deploy VueJs apps with Github Pages. Till then, Have fun. Cheers 🥳

E2E Testing with Cypress - 04 - Cucumber / Gherkin Integration

Kiran Parajuli — Fri, 06 Nov 2020 05:24:34 +0000

There is no official gherkin support available for Cypress, but there are nice libraries that add support for using feature files when testing with Cypress. Among them, we’re using cypress-cucumber-preprocessor in our project for automation testing.

To get started in Cypress with cucumber preprocessor, follow these simple steps:

Installation

npm install --save-dev cypress-cucumber-preprocessor

Cypress Configuration

Add it to your plugins cypress/plugins/index.js:

const cucumber = require('cypress-cucumber-preprocessor').default

module.exports = (on, config) => {
  on('file:preprocessor', cucumber())
}

Add support for feature files to your Cypress configuration cypress.json

{
  "testFiles": "**/*.feature"
}

Pre-processor Configuration

It lets you define the path to a folder containing step definitions required for your tests.

Where to define? 🤔

You can use cosmiconfig which helps to search for and loading configuration for your program. Or you can configure simply by adding this to your package.json.

{
    "cypress-cucumber-preprocessor": {
      "nonGlobalStepDefinitions": true
  }
}

Available Configurations

OPTION	DEFAULT	DESCRIPTION
`commonPath`	`cypress/integration/common` when `nonGlobalStepDefinitions` is true `cypress/support/step_definitions` when `nonGlobalStepDefinitions` is false `${nonGlobalStepBaseDir}/common` when `nonGlobalStepBaseDir` is defined	define the path to a folder containing all common step definitions of your tests.
`nonGlobalStepDefinitions`	`false`	If true use the Cypress Cucumber Preprocessor Style pattern for placing step definitions files.
`nonGlobalStepBaseDir`	`undefined`	If defined and `nonGlobalStepDefinitions` is also true then step definition searches for folders with the features name will start from the directory provided here.
`stepDefinitions`	`cypress/integration` when `nonGlobalStepDefinitions` is true `cypress/support/step_definitions` when `nonGlobalStepDefinitions` is false	Path to the folder containing our step definitions.

Organize Tests

Single feature files

After adding .feature support in cypress configuration, you can add feature files in cypress/integration/

You can easily integrate Background, Scenario Outlines, DataTables within a feature file.

Bundled feature files

When running Cypress tests in the headless mode, the execution time can get pretty bloated, this happens because by default Cypress will relaunch the browser between every feature file. The cypress-cucumber-preprocessor gives you the option to bundle all feature files before running the tests, therefore reducing the execution time.

You can take advantage of this by creating .features files. You choose to have only one in the root of the directory cypress/integrations or per directory.

Adding support for .features files to your Cypress configuration

cypress.json

{
  "testFiles": "**/*.{feature,features}"
}

Step Definitions

The steps in the .feature file look for their implementation inside a directory configured from preprocessor configuration. Step definitions files are by default in: cypress/support/step_definitions. If you want to put them somewhere else please use cosmiconfig format. For example, add to your package.json.

{
  "cypress-cucumber-preprocessor": {
    "step_definitions": "cypress/support/step_definitions/"
  }
}

An example of some step definitions done in the cypress way is as follows:

import { Given, Then } from "cypress-cucumber-preprocessor/steps";

const url = 'https://google.com'
Given('I open Google page', () => {
  cy.visit(url)
})
Then(`I see {string} in the title`, (title) => {
  cy.title().should('include', title)
})

Before and After hooks

The cypress-cucumber-preprocessor supports both Mocha’s before/beforeEach/after/afterEach hooks and Cucumber’s Before and After hooks.

The cucumber hooks implementation fully supports tagging as described in the cucumberJs documentation. So they can be conditionally selected based on the tags applied to the Scenario. This is not possible with Mocha hooks.

Example:

const { Before, After, Given, Then }
  = require("cypress-cucumber-preprocessor/steps");

// this will get called before each scenario
Before(() => {
  beforeCounter += 1;
  beforeWithTagCounter = 0;
});

// this will only get called before scenarios tagged with @foo
Before({ tags: "@foo" }, () => {
  beforeWithTagCounter += 1;
});

Given("My Step Definition", () => {
  // ...test code here
})

Note: to avoid confusion with the similarly named Mocha before and after hooks, the Cucumber hooks are not exported onto the global scope. So they need explicit importing as shown above.

Smart Tagging

Start your tests without setting any tags and then put a @focus on the scenario (or scenarios) you want to focus on while developing or bug fixing.

Feature: Smart Tagging

  As a cucumber cypress plugin which handles Tags
  I want to allow people to select tests to run if focused
  So they can work more efficiently and have a shorter feedback loop

  Scenario: This scenario should not run if @focus is on another scenario
    Then this unfocused scenario should not run

  @focus
  Scenario: This scenario is focused and should run
    Then this focused scenario should run

  @this-tag-affects-nothing
  Scenario: This scenario should also not run
    Then this unfocused scenario should not run

  @focus
  Scenario: This scenario is also focused and also should run
    Then this focused scenario should run

Run tests

Run your Cypress Launcher the way you would usually do.

yarn run cypress open

Then click on a .feature file on the list of specs, and see the magic happening!

Running tagged tests

  ./node_modules/.bin/cypress-tags run -e TAGS='not @foo and (@bar or @zap)'

Limiting to a subset of feature files

    ./node_modules/.bin/cypress-tags run -e GLOB='cypress/integration/**/*.feature'

You can also configure these from cypress configuration env property with TAGS sub-property.

  {
      "env": {
          "TAGS": "not @ignore"
      },
      //rest of configuration options
      "baseUrl": "yourBaseUrl",
      "ignoreTestFiles": "*.js"
      //etc
  }

What's next

Cool! 😎 I’m sure this will get you started with cypress running your test in the Gherkin theme. Throughout the series, I've discussed E2E testing with Cypress, but in the next part of the series, we will be comparing cypress with other e2e testing frameworks. Till then, bye-bye, sayonara

E2E Testing with Cypress -03 - Configure Cypress

Kiran Parajuli — Tue, 03 Nov 2020 05:47:08 +0000

Configure Cypress

When a project is added to Cypress, a cypress.json file is created in the project. This file is used to store the projectId (after configuring your tests to record) and any configuration values you supply.

Change Configuration File

You can change the configuration file or turn off the use of a configuration file by using the --config-file flag.

Options

The default behavior of Cypress can be modified by supplying any of the following configuration options.

Global

OPTION	DEFAULT	DESCRIPTION
`baseUrl`	`null`	URL used as prefix for `cy.visit()` or `cy.request()` command.
`env`	`{}`	Any values to be set as environment variables
`retries`	`{“runMode”: 0, “openMode: 0}`	The number of times to retry a failing test. See Test Retries for more information.
`defaultCommandTimeout`	`4000`	Time, in milliseconds, to wait until most DOM based commands are considered timed out.

Timeouts

OPTION	DEFAULT	DESCRIPTION
`defaultCommandTimeout`	`4000`	Time, in milliseconds, to wait until most DOM based commands are considered timed out.
`pageLoadTimeout`	`6000`	Time, in milliseconds, to wait for page transition events or `cy.visit()`, `cy.go()`, `cy.reload()` commands to fire their page load events.
`requestTimeout`	`5000`	Time, in milliseconds to wait for an XHR request to go out in a `cy.wait()` command

Folders / Files

OPTION	DEFAULT	DESCRIPTION
`testFiles`	`*/.`	A String or Array of glob patterns of the test files to load
`ignoreTestFiles`	`*.hot-update.js`	A String or Array of glob patterns used to ignore test files that would otherwise be shown in your list of tests.
`screenshotsFolder`	`cypress/screenshot`	Path to folder where screenshots will be saved from `cy.screenshot()` command or after a test fails during `cypress run`

Browser

OPTION	DEFAULT	DESCRIPTION
`chromeWebSecurity`	`true`	Whether to enable Chromium-based browser’s Web Security for same-origin policy and insecure mixed content.
`blockHosts`	`null`	A String or Array of hosts that you wish to block traffic for.
`viewportHeight`	`660`	Default height in pixels for the application under tests’ viewport (Override with `cy.viewport()` command)
`viewportWidth`	`1000`	Default width in pixels for the application under tests’ viewport. (Override with `cy.viewport()` command)
`animationDistanceThreshold`	`5`	The distance in pixels an element must exceed over time to be considered animating
`waitForAnimations`	`true`	Whether to wait for elements to finish animating before executing commands

Overriding Options

Cypress gives you the option to dynamically alter configuration values. This is helpful when running Cypress in multiple environments and on multiple developer machines. This gives you the option to do things like override the baseUrl or environment variables.

Command Line

When running Cypress from the Command Line you can pass a --config flag.

Examples:

cypress open --config pageLoadTimeout=30000,baseUrl=https://myapp.com

cypress run --config integrationFolder=tests,videoUploadOnPasses=false

cypress run --browser firefox --config viewportWidth=1280,viewportHeight=720

Environment Variables

You can also use environment variables to override configuration values. This is especially useful in Continuous Integration or when working locally. This gives you the ability to change configuration options without modifying any code or build scripts.

By default, any environment variable that matches a corresponding configuration key will override the configuration file (cypress.json ) by a default value.

export CYPRESS_VIEWPORT_WIDTH=800
export CYPRESS_VIEWPORT_HEIGHT=600

# Both options below are valid
export CYPRESS_pageLoadTimeout=100000
export CYPRESS_PAGE_LOAD_TIMEOUT=100000

Now, Cypress will strip off the CYPRESS_, camel-case any keys and automatically convert values into Number or Boolean. Make sure to prefix your environment variables with CYPRESS_ else they will be ignored.

`Cypress.config()`

You can also override configuration values within your test using Cypress.config().

Configuration set using Cypress.config is only in scope for the current spec file.

Cypress.config('pageLoadTimeout', 10000) // set value
Cypress.config('pageLoadTimeout') // => 100000 (get value)

Run in CI

You can easily integrate Cypress with your current CI provider. According to the official documentation, Cypress works with any CI Provider.

Features

Optimize tests
- See detailed insights into the performance of individual tests and specs to identify potential bottlenecks
- Automatic load balancing and parallelization ensure tests run as fast as possible
Maximize efficiency with parallelization

Split your tests across multiple CI machines and drastically reduce your run times

Slack Integration

The Cypress Slack application provides real-time results for your Cypress tests, all in one place—improving remote collaboration and giving wider visibility into test behavior.

Improve cross-team collaboration by instantly surfacing Cypress results to the teams that need visibility
Confirm that key tests pass prior to launching new products or features
Reduce the time it takes to catch failed tests

Github Integration

Cypress Dashboard tightly integrates your Cypress test runs with your GitHub workflow via commit status checks and pull-request comments.

Merge Confidently with Status Checks

Cypress Dashboard will report the status of test runs as GitHub commit status checks for every run group or every spec file in your test-suite so that you can prevent PR merges until all your tests pass.

Test Results in Your Workflow via Pull-Request Comments

Detailed test run information conveniently posted as PR comments that include tests run statistics, specific test failures, related screenshots and deep links to the Cypress Dashboard to help you quickly resolve problems.

What's Next?

These are some helpful strategies to configure Cypress. Hope you liked it. If you've any questions please do comment. We'll see you in the next part of the series with Gherkin Preprocessor in Cypress. Till then, have fun coding! 🕊 🙌

E2E Testing with Cypress - 02 - Writing Tests

Kiran Parajuli — Sun, 01 Nov 2020 06:29:42 +0000

Setting up the test

As we've discussed in the previous part of the series, there are no servers, drivers, or any other dependencies to install or configure. You can write your first passing test in seconds.

Add a test file

Assuming you've successfully installed the Test Runner and opened the Cypress application, now it's time to write our first test. We are going to:

Create a sample_spec.js file.
Watch Cypress update the list of specs
Launch the Cypress Test Runner

Let’s create a new file in the cypress/integration folder that was created for us:

touch {your_project}/cypress/integration/sample_spec.js

Once we’ve created that file, we should see the Cypress Test Runner immediately display it in the list of Integration Tests. Cypress monitors your spec files for any changes and automatically displays any changes.

Even though we haven’t written any tests yet - that’s okay - let’s click on sample_spec.js and watch Cypress launch your browser.

We are now officially in the Cypress Test Runner. This is where we will spend the majority of our time testing.

Notice: Cypress displays the message that it couldn't find any tests. This is normal - we haven’t written any tests! Sometimes you’ll also see this message if there was an error parsing your test file. You can always open your Dev Tools to inspect the Console for any syntax or parsing errors that prevented Cypress from reading your tests.

Add your test

Let's add our first passing test

Open up your favorite IDE and add the code below to our sample_spec.js test file.

describe('My First Test', () => {
  it('Does not do much!', () => {
    expect(true).to.equal(true)
  })
})

Once you save this file you should see the browser reload.

Although it does not do anything useful, this is our first passing test! ✅

Over in the Command Log you’ll see Cypress display the suite, the test and your first assertion (which should be passing in green).

Now let’s write our first failing test.

describe('My First Test', () => {
  it('Does not do much!', () => {
    expect(true).to.equal(false)
  })
})

Once you save again, you’ll see Cypress display the failing test in the red since true does not equal false.

Cypress also displays the stack trace and the code frame where the assertion failed (when available). You can click on the blue file link to open the file where the error occurred in your preferred file opener.

Cypress provides a nice Test Runner that gives you a visual structure of suites, tests, and assertions.

Dig Deeper Into Cypress World

Writing and Organizing Tests

Folder Structure

After adding a new project, Cypress will automatically scaffold out a suggested folder structure. All test artifacts are wrapped inside a folder named cypress. See in detail here but these are always configurable. You can modify the folder configuration in your configuration file.

Types

Generally, two types of files are used inside cypress.

Fixtures:

These JSON fixture files are used as external pieces of static data that can be used by your test. It is placed in cypress/fixtures by default but can be configured to another directory.
TestFiles:

The actual test files are located in cypress/integration by default, but as always, it is configurable. Test files may be written as: .js, .jsx, .coffee, .cjsx.

Basic Test Syntax

describe(name, config, fn)
context(name, config, fn)
it(name, config, fn)
specify(name, config, fn)

Other Artifacts

You can always tweak your test with before and after hooks.


  beforeEach(() => {
      // root-level hook
      // runs before every test
  })
  describe("Hooks", () => {
    before(() => {}) // runs once before all tests in the block
    beforeEach(() => {}) // runs before each test in the block
    afterEach(() => {}) // runs after each test in the block
    after(() => {}) // runs once after all tests in the block
  })

You can run a specified suite or test. Excluding and including tests is made easier. To skip a specified suite or test, append .skip() to the function. All nested suites will also be skipped.
```
  it.skip('returns "fizz" when number is multiple of 3', () => {
    numsExpectedToEq([9, 12, 18], 'fizz')
  })
```

Cypress Commands

Querying Elements

If you’ve used jQuery before, you may be used to querying for elements like this:

$('.my-selector')

In Cypress, querying elements is the same:

cy.get('.my-selector')

In fact, Cypress bundles jQuery and exposes many of its DOM traversal methods to you so you can work with complex HTML structures with ease using APIs you’re already familiar with.

// Each method is equivalent to its jQuery counterpart. Use what you know!
cy.get('#main-content')
  .find('.article')
  .children('img[src^="/static"]')
  .first()

Interested in the best practices for selecting elements? Read here
Cypress wraps all DOM queries with robust retry-and-timeout logic that better suits how real web apps work. We trade a minor change in how we find DOM elements for a major stability upgrade to all of our tests. Banishing flake for good!

In Cypress, when you want to interact with a DOM element directly, call .then() with a callback function that receives the element as its first argument. When you want to skip the retry-and-timeout functionality entirely and perform traditional synchronous work, use Cypress.$!

cy
  // cy.get() looks for '#element-does-not-exist', repeating the query until...
  // ...it times out without finding the element.
  // Cypress halts and fails the test.
  .get('#element-does-not-exist')
  // ...this code is never run...
  .then(($myElement) => {
    doSomething($myElement)
  })

When Elements Are Missing

Cypress anticipates the asynchronous nature of web applications and doesn't fail immediately the first time an element is not found. Instead, Cypress gives your application a window of time to finish whatever it may be doing!

This is a known timeout, and most commands can be customized with specific timeout periods. These commands will list a timeout option in their API documentation, detailing how to set the number of milliseconds you want to continue to try finding the element.

// Give this element 10 seconds to appear
cy.get('.my-slow-selector', { timeout: 10000 })

You can also set the timeout globally via the configuration setting: defaultCommandTimeout.

Querying by Text Content

Another way to locate things - a more human way - is to look them up by their content, by what the user would see on the page. For this, there’s the handy cy.contains() command, for example:

// Find an element in the document containing the text 'New Post'
cy.contains('New Post')
// Find an element within '.main' containing the text 'New Post'
cy.get('.main').contains('New Post')

Interacting With Elements

Cypress allows you to click on and type into elements on the page by using .click() and .type() commands with a cy.get() or cy.contains() command. This is a great example of chaining in action. Let’s see it again:

cy.get('textarea.post-body')
  .clear()
  .type('This is an excellent post.')
  .should('have.text', 'This is an excellent post.')

Some more commands in Cypress for interacting with the DOM are:

.blur(), .focus(), .check(), .uncheck(), .select(), .click(), .dblclick(), .rightclick()

Asserting About Elements

Assertions let you do things like ensuring an element is visible or has a particular attribute, CSS class or state. Assertions are commands that enable you to describe the desired state of your application.

There are two ways to write assertions in Cypress:

Implicit Subjects:

Using .should() or .and() commands is the preferred way of making assertions. These are typical Cypress commands, which means they apply to the currently yielded subject in the command chain.


   // the implicit subject here is the first <tr>
   // this asserts that the <tr> has an .active class
   cy.get('tbody tr:first').should('have.class', 'active')
   // you can chain multiple assertions as
   cy.get('#header a')
     .should('have.class', 'active')
     .and('have.attr', 'href', '/users')
     .and('not.have.descendants')

Explicit Subjects:

Using expect allows you to pass in a specific subject and make an assertion about it. This is probably how you’re used to seeing assertions written in unit tests:
```
   expect(true).to.be.true
```
Explicit assertions are great when you want to.
- Perform custom logic prior to making the assertion.
- Make multiple assertions against the same subject.

In each of these examples, it’s important to note that Cypress will automatically wait until these assertions pass or fail the test if the assertions don’t pass. See more about Cypress assertions here.

Cypress Commands are Asynchronous

It is very important to understand that Cypress commands don’t do anything at the moment they are invoked, but rather enqueue themselves to be run later.

Let's understand with an example:

❌ Incorrect Usage

In the example below, the check on the username value gets evaluated immediately, before cy.visit() has executed, so will always evaluate to undefined.

it('test', () => {
  let username = undefined     // evaluates immediately as undefined
  cy.visit('https://app.com') // Nothing happens yet
  cy.get('.user-name')        // Still, nothing happens yet
    .then(($el) => {          // Nothing happens yet
      // this line evaluates after the .then executes
      username = $el.text()
    })
  // this evaluates before the .then() above
  // so the username is still undefined
  if (username) {             // evaluates immediately as undefined
    cy.contains(username).click()
  } else {
    // this will always run
    // because username will always
    // evaluate to undefined
    cy.contains('My Profile').click()
  }
})

✅ Correct Usage:

Below is one way the code above could be rewritten in order to ensure the commands run as expected.

it('test', () => {
  let username = undefined     // evaluates immediately as undefined
  cy.visit('https://app.com') // Nothing happens yet
  cy.get('.user-name')        // Still, nothing happens yet
    .then(($el) => {          // Nothing happens yet
      // this line evaluates after the .then() executes
      username = $el.text()
      // evaluates after the .then() executes
      // it's the correct value gotten from the $el.text()
      if (username) {
        cy.contains(username).click()
      } else {
        cy.get('My Profile').click()
      }
    })
})
// Ok, the test function has finished executing...
// We've queued all of these commands and now
// Cypress will begin running them in order!

Commands are Promises

This is one of the big secrets of Cypress. We’ve said above, cypress enqueues actions to be taken later, we could restate that as “adding Promises to a chain of Promises”.

Noisy Promise demonstration. Not valid code

it('changes the URL when "awesome" is clicked', () => {
  // THIS IS NOT VALID CODE.
  // THIS IS JUST FOR DEMONSTRATION.
  return cy.visit('/my/resource/path')
  .then(() => {
    return cy.get('.awesome-selector')
  })
  .then(($element) => {
    // not analogous
    return cy.click($element)
  })
  .then(() => {
    return cy.url()
  })
  .then((url) => {
    expect(url).to.eq('/my/resource/path#awesomeness')
  })
})

How Cypress really looks, Promises wrapped up and hidden from us

it('changes the URL when "awesome" is clicked', () => {
  cy.visit('/my/resource/path')
  cy.get('.awesome-selector')
    .click()
  cy.url()
    .should('include', '/my/resource/path#awesomeness')
})

Big difference! In addition to reading much cleaner, Cypress does more than this, because Promises themselves have no concepts of retry-ability.

Without retry-ability, assertions would randomly fail. This would lead to flaky, inconsistent results. This is also why we cannot use new JS features as async / await.

Commands Are Not Promises

The Cypress API is not an exact 1:1 implementation of Promises. They have Promise qualities and yet there are important differences you should be aware of.

You cannot race or run multiple commands at the same time (in parallel).
You cannot ‘accidentally’ forget to return or chain a command.
You cannot add a .catch error handler to a failed command.

Variables and Aliases

Variables

Typically, in Cypress, you hardly need to ever use const, let, or var. When using closures you’ll always have access to the objects that were yielded to you without assigning them.

The one exception to this rule is when you are dealing with mutable objects (that change state). When things change state you often want to compare an object’s previous value to the next value.

Demonstration

<!-- app code -->
<html lang="en">
    ...
    <button id='increase'>increment</button>
    you clicked button <span id='num'>0</span> times!

    <script>
        let count = 0
        $('#increase').on('click', () => {
            $('#num').text(count += 1)
        })
    </script>
</html>

// cypress test code
cy.get('#num').then(($span) => {
  // capture what num is right now
  const num1 = parseFloat($span.text())
  cy.get('button').click().then(() => {
    // now capture it again
    const num2 = parseFloat($span.text())
    // make sure it's what we expected
    expect(num2).to.eq(num1 + 1)
  })
})

Aliases

Using .then() callback functions to access the previous command values is great—but what happens when you’re running code in hooks like before or beforeEach?

We could make our code do some ugly backflips using global variables but with cypress NOT ANYMORE.

Let's look at a cool example with aliases:

beforeEach(() => {
  // alias the $btn.text() as 'text'
  cy.get('button').invoke('text').as('text')
  cy.fixture('users.json').as('users')
  // alias all of the tr's found in the table as 'rows'
  cy.get('table').find('tr').as('rows')
})
it('has access to text', function () {
  // is now available
  this.text
  // access the users property
  const user = this.users[0]
  // Cypress returns the reference to the <tr>'s which allows
  // us to continue to chain commands finding the 1st row.
  cy.get('@rows').first().click()
})

You can also easily alias network requests and access the properties later.

cy.request('https://jsonplaceholder.cypress.io/comments').as('comments')
// other test code here
cy.get('@comments').should((response) => {
  if (response.status === 200) {
      expect(response).to.have.property('duration')
    } else {
      // whatever you want to check here
    }
})

References

What's Next?

I hope this helped you. The Cypress documentation is itself a great resource to peek in. Let me know what you think in the comments below. In the next part, we'll be discussing how configurable is Cypress and how can we tweak it according to our needs. Till then, Happy Coding! 🥳 🙋‍♂️

E2E Testing with Cypress - 01 - Introduction

Kiran Parajuli — Fri, 30 Oct 2020 10:16:55 +0000

The web has evolved. Finally, testing has too. Cypress provides fast, easy, and reliable testing for anything that runs in a browser.

Introduction

Cypress provides a complete end-to-end testing experience. Until now, end-to-end testing was not easy. It was the part developers always hated but not anymore. Cypress makes setting up, writing, running, and debugging tests easy.

Who uses Cypress?

Cypress users are typically developers or QA engineers building web applications using modern JavaScript frameworks.

Cypress enables you to write all type of tests:

End-to-end tests
Integration tests
Unit tests

Cypress can test anything that runs in a browser.

How Cypress is different?

Cypress does not use Selenium

The architecture is completely different. Most end-to-end testing tools operate by running outside of the browser and executing remote commands across the network. Cypress is the exact opposite. Cypress is executed in the same run loop as your application. Behind Cypress is a Node.js server process. Cypress and the Node.js process constantly communicate, synchronize, and perform tasks on behalf of each other. Having access to both parts (front and back) gives us the ability to respond to your application’s events in real-time, while at the same time, work outside of the browser for tasks that require a higher privilege.
Cypress tests are only written in JavaScript

Cypress tests anything that runs in a web browser. All the architecture surrounding Cypress is built to handle modern JavaScript frameworks especially well. We have hundreds of projects using the latest React, Angular, Vue, Elm, etc. frameworks. Cypress also works equally well on older server-rendered pages or applications.
Cypress is all in one

Writing end-to-end tests takes a lot of different tools to work together. With Cypress, you get multiple tools in one. There is no need to install 10 separate tools and libraries to get your test suite set up. We have taken some best-in-class tools you are likely already familiar with and made them all work together seamlessly.
Cypress is for developers and QA Engineers

One of our goals was to make test-driven development a reality for end-to-end testing. Cypress is at its best when you use it as you build your application. We give you the power to code as fast as possible.
Cypress runs much, much faster

These architectural improvements unlock the ability to do TDD with full end-to-end tests for the very first time. Cypress has been built so that testing and development can happen simultaneously. You can develop faster while driving the entire dev process with tests.

Features

Time Travel:

Yes, you heard it right. Time travel is finally possible. Cypress takes snapshots as your tests run. Hover over the commands in the Command Log to see exactly what happened at each step.
Real-Time Reloads:

Cypress automatically reloads whenever you make changes to your tests. See commands execute in real-time in your application.
Automatic Waiting:

Never add wait or sleep to your tests. Cypress automatically waits for commands and assertions before moving on. No more async hell.
Spies, Stubs & Clocks:

Verify and control the behavior of functions, server responses, or timers. The same functionality you love from unit testing is right at your fingertips.
Network Traffic Control:

Easily control, stub, and test edge cases without involving your server. You can stub network traffic however you like.
Screenshot and Videos:

View screenshots taken automatically on failure, or videos of your entire test suite when run from the CLI.
Cross Browser Testing:

Run tests within Firefox and Chrome-family browsers (including Edge and Electron) locally and optimally in a continuous integration pipeline.

Installation And Requirements

System Requirement
- OS
  
  Cypress is a desktop application that is installed on your computer. The desktop application supports these operating systems:
  - macOS: 10.9 and above (64-bit only)
  - Linux: Ubuntu 12.04 and above, Fedora 21 and Debian 8 (64-bit only)
    - For Ubuntu/Debian
```
  sudo apt-get install libgtk2.0-0 libgtk-3-0 libgbm-dev libnotify-dev libgconf-2-4 libnss3 libxss1 libasound2 libxtst6 xauth xvfb
```
    - For CentOS
```
  yum install -y xorg-x11-server-Xvfb gtk2-devel gtk3-devel libnotify-devel GConf2 nss libXScrnSaver alsa-lib
```
  - Windows: 7 and above
Node.js

If you're using npm to install Cypress, then
Node.js 10 or 12 and above
Installing

The recommended approach is to install Cypress with npm because :
- Cypress is versioned like any other dependency.
- It simplifies running Cypress in Continuous Integration.
```
  cd /your/project/path
  npm install cypress --save-dev
```
  Or, you could always install with yarn
```
  cd /your/project/path
  yarn add cypress --dev
```
Opening Cypress

If you used npm to install, Cypress has now been installed to your ./node_modules directory, with its binary executable accessible from ./node_modules/.bin.

Now you can open Cypress from your project root one of the following ways:
- Use the shortcut using npm bin
```
  $(npm bin)/cypress open
```
- Adding npm scripts
  
  Inside your package.json file:
```
  {
      "scripts": {
          "cypress:open": "cypress open"
      }
  }
```
  Now you can invoke the command from your project root like so:
```
  npm run cypress:open
```
- You can always use other options like yarn or npx to open Cypress.
```
  # using yarn
  yarn run cypress open
  # using yarn
  npx cypress open
```

What's next?

🎉 That's it! You can now set up Cypress as a testing framework for your project. In the next parts of this series, we will guide you to write, run, and debug tests using Cypress technology. If you have any thoughts or comments about the post, please do comment. Till then, Cheers. 🥳 🙌

Forem: Kiran Parajuli

Dockerizing Your Django Vue Application: A Step-by-Step Guide

Prerequisites

Folder Structure

Dockerfile for Django Application

Gunicorn Configuration

Dockerfile for Backend

Dockerfile for Frontend

Docker compose

To break it down:

Running the application

Conclusion

Congratulations, you've successfully dockerized your Django Vue application! Now, you can deploy it to your preferred cloud provider or use it for the development environment. Happy coding!

Unit testing Vue components

Why Unit Testing?

Vue Test Utils (VTU)

Installation

Writing Tests

Knowing what to test

mount and shallowMount

Stubs

Mocks

Spying

User Interactions

Snapshots

Curious how snapshots are saved and maintained?

Final Thoughts

NightwatchJs and GitHub Actions

NightwatchJs

GitHub Actions

Setup CI/CD

Webdriver

Setup workflow

Check your builds

What I love about GitHub CI

Splat Operator in PHP

Latest feature

E2E Testing with Cypress -06- Cypress - Gherkin / Parallelization

Parallelization with cucumber-preprocessor and Cypress

Example .gitlab-ci.yml

Test Results and Debugging

E2E Testing with Cypress -05- Trade-offs In Cypress

Key Differences

Key differences with other testing frameworks

Permanent trade-offs

Temporary trade-offs

Problems I faced with my project's tests

What's Next 😎?

Deploy Static Web Apps with GitHub Pages

GitHub Pages

Deploy Your Project

Create a repository

Clone the repository

Hello World

Push it

Done

Whats Next?

E2E Testing with Cypress - 04 - Cucumber / Gherkin Integration

Installation

Cypress Configuration

Pre-processor Configuration

Where to define? 🤔

Available Configurations

Organize Tests

Single feature files

Bundled feature files

Step Definitions

Before and After hooks

Smart Tagging

Run tests

What's next

E2E Testing with Cypress -03 - Configure Cypress

Configure Cypress

Options

Overriding Options

Command Line

Environment Variables

Cypress.config()

Run in CI

Features

`mount` and `shallowMount`

Example `.gitlab-ci.yml`

`Cypress.config()`