Testing for the Modern Web with Playwright – Arjun Attam

Talk: Testing for the Modern Web with Playwright

Abstract:
The modern web platform is continuously evolving. Today’s web apps are more sophisticated than ever before and testing for the modern web requires modern primitives. In this talk, we will cover how Playwright is uniquely enabling web developers to ship faster and more confidently.

#testing #web-development

What is GEEK

Buddha Community

Testing for the Modern Web with Playwright – Arjun Attam

Ray Patel

1623941220

Advance Web Penetration Testing Tool For Python

Features 🎭

Admin Panel Finder

Admin Scanner

Dork Generator

Advance Dork Finder

Extract Links

No Redirect

Hash Crack (Online-Database)

Hash Crack (Wordlist)

Whois Lookup

Tcp Port Scan

Geo IP Lookup

Reserve Analysts Search

Csrf Vernavility Checker

Dns-Lookup,Zone-Transfer,Reserve-IP-Lookup,Http-Headers,Subnet-Lookup

WordPress Username Finder

#testing #advance web penetration testing tool for python #python #advance web penetration #testing tool for python #web

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

Nicolette Zboncak

1620983255

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

Donna Corriveau

1656302303

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

Willy Cruickshank

1615468156