Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Add config setting to fail if the app writes to the console. #27277

Closed
coryhouse opened this issue Sep 24, 2023 · 6 comments
Closed

Comments

@coryhouse
Copy link

It's a good idea to keep the console clean. So, I'd like to assure that my app never writes to the console when any pages are loaded by Playwright.

I'm doing this right now by calling this util function at the top of each test:

// test-utils.ts
import { Page } from "@playwright/test";

// To keep the console clean, throw an error to fail the test immediately if a console message occurs.
export function throwOnConsole(page: Page) {
  page.on("console", (message) => {
    // Optionally, can check for only errors like this: if (message.type() === "error") {
    throw new Error(message.text());
  });
}

Ideally, I could just configure a setting that does this. The setting could let me specify which types of console logs should fail my tests.

Perhaps like this:

  failOnConsoleLog: ["error", "log", "warning"]
@coryhouse coryhouse changed the title [Feature]: Add setting to config to fail any tests that write to the console. [Feature]: Add config setting to fail if the app writes to the console. Sep 24, 2023
@yury-s
Copy link
Member

yury-s commented Sep 25, 2023

You can implement this today by either adding console listener in beforeEach and then checking that there were no console messages in afterEach or override page fixture to check the same:

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

export const test = base.extend({
  page: async ({ baseURL, page }, use) => {
    const messages = [];
    page.on('console', m => messages.push(m)); 
    await use(page);
    expect(messages).toEqual([]);
  },
});

@yury-s yury-s closed this as completed Sep 25, 2023
@evnp
Copy link

evnp commented Dec 12, 2023

The problem with the suggested solution here is that you must wait for the entire test to complete (pass or fail) before afterEach is run and your error-detection takes place. This can take a while for complex tests especially if waits and retry logic are involved.

@coryhouse's solution works for us and makes the test fail immediately with useful error output, sometimes saving many minutes of developer time (that would be spent waiting on tests). It would be great to have something like this as a config option though.

@karlhorky
Copy link
Contributor

karlhorky commented Mar 12, 2024

@yury-s what are your thoughts on the comment by @evnp on the limitations of your suggested approaches?

Would the Playwright team re-consider adding this as an option? (integrated in Playwright core, failing immediately)

This would be super useful to throw errors on things like CSP errors (Content Security Policy) - which currently do not fail the test if an inline <script> or other resource cannot be loaded (even with bypassCSP: false)

@karlhorky
Copy link
Contributor

karlhorky commented Apr 29, 2024

Another pattern that seems like it would also be good to have a configuration pattern for would be "failing on error", which can be achieved with this:

page.on('pageerror', (error) => {
  throw error;
});

References:

Would also be great to have this be added as a Playwright configuration option like failOnPageError or failOnUnhandledException, also commented over here:

@corneliusroemer
Copy link
Contributor

corneliusroemer commented May 12, 2024

I think one needs to modify the import to add type after import to @coryhouse's solution like so:

import type { Page } from '@playwright/test';

export function throwOnConsole(page: Page) {
    page.on('console', (message) => {
        throw new Error(message.text());
    });
}

@nboisteault
Copy link

So this issue should be reopened as there is no config settings today?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants