Demo.Playwright: Various Testing Scenarios with Playwright

🎭 demo.playwright

This repo is used to demo various testing scenarios with Playwright 🎭, using the official test-runner and scripts authored in TypeScript.

The test.yml GitHub Action workflow is used to:

Run Playwright example tests

accessibility - runs accessibility checks against https://www.w3.org

android - runs a basic test using Android's WebView.

basic - basic tests to show interactions, element selectors, assertions, upload files, read a response, mock a response, and page object model (POM).

chrome-extension - basic test that gets a handle to the background page of Chrome extension.

drag-and-drop - runs example drag-and-drop test utilizing https://www.w3schools.com/html/html5_draganddrop.asp.

electron - runs a basic test for Electron application, controlling main electron process and working with Electron window.

fixtures - runs example tests utilizing test and worker fixtures.

github-api - uses GitHub API to test creation of a new repo, bug, and feature, then deletion of repo.

oauth - runs oauth tests for LinkedIn, Facebook, and Google, to login to https://courses.ultimateqa.com/users/sign_in.

performance - web performance tests using resource timing API, DevTools, and lighthouse, run against https://fastestwebsite.net

svgomg - End-to-end tests for SVGOMG! site, hosted at https://demo.playwright.dev/svgomg

todomvc - End-to-end tests for ToDoMVC site, hosted at https://demo.playwright.dev/todomvc

visual-comparison - visually compares snapshots with golden screenshots and text content for playwright.dev landing page.

Publish each HTML report to their respective directory

When the above tests are finished, the results are published to GitHub pages:

Configuration

The baseURL value for most tests is set as a workflow environment variable. This allows flexibility for the URL of the sites tested. By not hardcoding a URL in page.goTo('') we can simply pass baseURL without changing the test script e.g. test.site.com -> stage.site.com -> prod.site.com

Have a testing scenario you'd like to see included?

Please open an issue with details.

Author: MarcusFelling
Source Code: https://github.com/MarcusFelling/Demo.Playwright 
License: Apache-2.0 license

#node #playwright #demo #testing #typescript 

What is GEEK

Buddha Community

Demo.Playwright: Various Testing Scenarios with Playwright

Demo.Playwright: Various Testing Scenarios with Playwright

🎭 demo.playwright

This repo is used to demo various testing scenarios with Playwright 🎭, using the official test-runner and scripts authored in TypeScript.

The test.yml GitHub Action workflow is used to:

Run Playwright example tests

accessibility - runs accessibility checks against https://www.w3.org

android - runs a basic test using Android's WebView.

basic - basic tests to show interactions, element selectors, assertions, upload files, read a response, mock a response, and page object model (POM).

chrome-extension - basic test that gets a handle to the background page of Chrome extension.

drag-and-drop - runs example drag-and-drop test utilizing https://www.w3schools.com/html/html5_draganddrop.asp.

electron - runs a basic test for Electron application, controlling main electron process and working with Electron window.

fixtures - runs example tests utilizing test and worker fixtures.

github-api - uses GitHub API to test creation of a new repo, bug, and feature, then deletion of repo.

oauth - runs oauth tests for LinkedIn, Facebook, and Google, to login to https://courses.ultimateqa.com/users/sign_in.

performance - web performance tests using resource timing API, DevTools, and lighthouse, run against https://fastestwebsite.net

svgomg - End-to-end tests for SVGOMG! site, hosted at https://demo.playwright.dev/svgomg

todomvc - End-to-end tests for ToDoMVC site, hosted at https://demo.playwright.dev/todomvc

visual-comparison - visually compares snapshots with golden screenshots and text content for playwright.dev landing page.

Publish each HTML report to their respective directory

When the above tests are finished, the results are published to GitHub pages:

Configuration

The baseURL value for most tests is set as a workflow environment variable. This allows flexibility for the URL of the sites tested. By not hardcoding a URL in page.goTo('') we can simply pass baseURL without changing the test script e.g. test.site.com -> stage.site.com -> prod.site.com

Have a testing scenario you'd like to see included?

Please open an issue with details.

Author: MarcusFelling
Source Code: https://github.com/MarcusFelling/Demo.Playwright 
License: Apache-2.0 license

#node #playwright #demo #testing #typescript 

Tamia  Walter

Tamia Walter

1596754901

Testing Microservices Applications

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

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

A Brave New World

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

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

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

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

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

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

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

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

Contract Testing as an Approach

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

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

Ways to Test Microservices

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

There are several ways to test microservices too, including:

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

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

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

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

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

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

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

What is Playwright Test | How to use Playwright Test to Run Unit Tests

A comparison of Playwright's new test runner versus 'traditional' approaches like Jest and Mocha

Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API. Playwright is built to enable cross-browser web automation that is ever-green, capable, reliable and fast.

Why you might want to use Playwright Test as a test runner for unit tests, and how to fill in missing pieces (e.g. code coverage).

In this blog post, I want to

  • describe what I like about Playwright and why I think it can be a good choice for unit testing
  • outline things missing from Playwright compared to other test frameworks (and how to fill some of those gaps)
  • suggest some minor tweaks to make Playwright more suitable for unit tests

Why to use Playwright Test for unit tests

I had used "traditional" test runners before, mainly Jest, but also Mocha a few years ago.
I think there are some advantages of using Playwright for unit tests:

Same tool for E2E tests and unit tests: One tool less in your setup means one tool less to learn, configure, update, etc.

Out-of-the-box support for TypeScript: Playwright Test supports TypeScript out-of-the-box.
For all other test runners I am aware of you have to configure some transform (Babel, ts-jest, etc.), or run the test runner with ts-node, or compile the test cases before running them (see e.g. "Using Typescript" of the Jest docs).

Access to features unique to Playwright: Playwright has some very useful features, e.g.:

"fixtures" allow to prepare resources per test case on an "opt-in" basis.
This is in my opinion much better than the beforeEach / afterEach fiddling you have to do with other test runners.

// base.ts
import { test as base } from '@playwright/test';
import * as sinon from 'sinon';

export const test = base.extend<{ fakeClock: sinon.SinonFakeTimers }>({
  fakeClock: [
    async ({}, use) => {
      const clock = sinon.useFakeTimers();
      await use(clock);
      clock.restore();
    },
    { scope: 'test' },
  ],
});

// FILE: bar.spec.ts
import { test } from './base';

test('with real clock', ({}) => {
  /*
   * this test case does not use the "fakeClock" fixture,
   * thus the fixture does not get set up
   */
});
test('with fake clock', ({ fakeClock }) => {
  /*
   * fake timers will get set up for this test case
   * because "fakeClock" fixture is used
   */
});

"projects" allow to run "the same or different tests in multiple configurations".
For example a while ago I had to make sure that some client/server interaction based on socket.io works with both WebSockets and HTTP long-polling.
Setting up two Playwright projects with different project parameters allowed me to run the same tests with two configurations, once using WebSockets and once using HTTP long-polling:

// playwright.config.ts
import { PlaywrightTestConfig } from '@playwright/test';

interface TestOptions {
  transport: 'websocket' | 'polling';
}

const config: PlaywrightTestConfig<TestOptions> = {
  projects: [
    {
      name: 'using transport: websocket',
      use: { transport: 'websocket' },
    },
    {
      name: 'using transport: polling',
      use: { transport: 'polling' },
    },
  ],
};

export default config;

// FILE: bar.spec.ts
import { test } from '@playwright/test';

test('socket.io connection', ({ transport }) => {
  /*
   * this test case will get run twice,
   * with "transport" set once to "websocket" and once to "polling"
   */
  initializeSocket(transport);
  // ...
});

Development funded by a big company: Playwright is a product of Microsoft and has been maintained very actively over the last couple of years.

No use of globals: Playwright does not use any globals for its test runner. You import from @playwright/test just what you need in your test files:

// FILE bar.spec.ts
import { expect, test } from '@playwright/test';

test.describe('describe title', () => {
  test('test title', ({}) => {
    expect(1 + 1).toEqual(2);
  });
});

Compare that to existing test runners like Jest and Mocha (and Cypress, using Mocha under-the-hood). Those test runners set up their test functions as globals (it, expect, describe, beforeEach etc.).
In TypeScript projects, as soon as you install any two of these test libraries you end up with TypeScript compilation errors, since the types of those functions are usually not compatible with each other. There are a couple of workarounds to avoid those compilation errors, for example fiddling with (multiple) tsconfig.json files such that types of these libraries are excluded.
Cypress even has a guide dedicated to this problem (docs.cypress.io/guides/tooling/typescript-support#Clashing-types-with-Jest).

Having the same import statements from @playwright/test in every test file might be some boilerplate, but I think the reduced friction (by not having any globals) justifies that boilerplate.
Newer test runners like vitest also do not set globals anymore.

Things missing from Playwright (and how to fill the gaps)

Compared to Jest, there are some things missing from Playwright Test which are often needed when running unit tests.
Most of those things can be substituted by using libraries of the Node.js ecosystem.
Take a look at the example repository I made to see how to set up those things!

For Mocks & Spies use sinon or jest-mock (the mocking solution shipped with Jest).

For Fake timers use sinon (See code changes).

Code coverage just needs a simple combination of the command-line interface nyc of Istanbul (a code coverage tool for JavaScript) and source-map-support (See code changes).

Watch mode is not supported but "planned work" at the time of writing: playwright.dev/docs/test-components#planned-work.
There are some workarounds in the related issue: github.com/microsoft/playwright/issues/7035.

Some test frameworks provide a way to mock CommonJS/ECMAScript modules.
Module mocking allows to replace the "thing" returned by require/import statements by some fake instance.

Unfortunately, this is not possible in Playwright. Although there are some Node.js libraries that allow module mocking (like testdouble), they don't work because Playwright does some of the module loading itself (github.com/microsoft/playwright/issues/14398).
If you want to get module mocking support in Playwright, you can upvote this feature request: github.com/microsoft/playwright/issues/14572.

This is the biggest downside of using Playwright for unit tests in my opinion.
For now, if you want to test modules isolated from others you probably have to adapt the codebase to use some kind of dependency injection. Be it that dependencies are just passed as arguments when calling functions, or using a dependency injection solution like NestJS IoC containers (which I have used very successfully in the past).

One last thing

Playwright Test has a method expect(...).toMatchSnapshot(...) which can perform snapshot-comparisons on screenshots but also textual and binary data.

At the time of writing, Playwright will append a platform-specific suffix (like linux) to the name of the file the snapshot is stored in. This makes sense for screenshots (since screenshots taken on different platforms will deviate slightly, for example because of text rendering), but it rarely makes sense in case of textual/binary data.

This is an open issue (github.com/microsoft/playwright/issues/11134). An easy workaround is to disable the suffix by setting up an "auto-fixture" and override testInfo.snapshotSuffix:

import { test as base } from '@playwright/test';

export const test = base.extend<{ _autoSnapshotSuffix: void }>({
  _autoSnapshotSuffix: [
    async ({}, use, testInfo) => {
      testInfo.snapshotSuffix = '';
      await use();
    },
    { auto: true },
  ],
});

#testing #playwright #test 

Dejah  Reinger

Dejah Reinger

1599859380

How to Do API Testing?

Nowadays API testing is an integral part of testing. There are a lot of tools like postman, insomnia, etc. There are many articles that ask what is API, What is API testing, but the problem is How to do API testing? What I need to validate.

Note: In this article, I am going to use postman assertions for all the examples since it is the most popular tool. But this article is not intended only for the postman tool.

Let’s directly jump to the topic.

Let’s consider you have an API endpoint example http://dzone.com/getuserDetails/{{username}} when you send the get request to that URL it returns the JSON response.

My API endpoint is http://dzone.com/getuserDetails/{{username}}

The response is in JSON format like below

JSON

{
  "jobTitle": "string",
  "userid": "string",
  "phoneNumber": "string",
  "password": "string",
  "email": "user@example.com",
  "firstName": "string",
  "lastName": "string",
  "userName": "string",
  "country": "string",
  "region": "string",
  "city": "string",
  "department": "string",
  "userType": 0
}

In the JSON we can see there are properties and associated values.

Now, For example, if we need details of the user with the username ‘ganeshhegde’ we need to send a **GET **request to **http://dzone.com/getuserDetails/ganeshhegde **

dzone.com

Now there are two scenarios.

1. Valid Usecase: User is available in the database and it returns user details with status code 200

2. Invalid Usecase: User is Unavailable/Invalid user in this case it returns status with code 404 with not found message.

#tutorial #performance #api #test automation #api testing #testing and qa #application programming interface #testing as a service #testing tutorial #api test