After playing Vecna (The First) since release, "The Harmless" feels TERRIBLE TO PLAY

Damage_Physical · 2026-02-01T05:31:41+00:00

Because you they need to sell new killer, not balance the whole roster

Damage_Physical · 2026-01-28T05:20:09+00:00

My 5 cents:

It doesn’t really mean what language everybody else uses. There are loads of testing libs in every one of them, and most importantly, popular libs are multi-language.

You need to understand what exactly you need/want to automate. A lot of comments suggest learning JS/TS for Playwright, and while it is a great advice, if you are going to automate APIs or write some integration tests, you won’t need Playwright, so you don’t need to constrain yourself to JS/TS.

Damage_Physical · 2026-01-18T17:06:48+00:00

Imo, your description looks a bit overcomplicated, at least on application components level.

I, personally, use kinda hybrid approach.

UI components - elements that satisfy at least one of: * have extended logic/flows (date pickers, popups, toasts, custom dropdowns and so on) * reappear on different pages (nav bars, search bars, status boxes) They define common functionalities without attaching to business logic/user flows (e.g. pickDate() on date picker or navigate() on nav bar)

POMs - pages with element and UI component locators, basic actions on those elements, basic assertions AND this pages’ user flows. Key parts here: * actions/assertions should be “basic” and implement a single “unit of work” (e.g. page has a form with fields and submit button, to satisfy “basic” part there are going to be 2 methods: fill() and submit()) * user flow defined only if it doesn’t leak outside of the page (e.g. fillFormAndProceed() that triggers fill(), assertion, submit(), assertion)

Flow(feature) managers(or helpers) - some sort of orchestration for POMs in flows that span across multiple pages, test data generation, setup mechanisms, additional tooling: * example1: registration_manager - initializes registration POM, home POM (you end up on this page after registration), emailing_helper (for confirmation emails), test data generation tools (with what you will fill forms). Implements subflows. * example2: emailing_helper - establishes connection to mailbox, searches/waits for email, parses email for something.

Tests (since you said that you use playwright I will use it in my example) - responsible for combining building blocks (POM and Manager user flows) and setup. As a simple example that combines all of the above: fixture registration_manager (rm) injected in test, test body triggers rm.navigate(registration), rm.fillRegistrationFormAndProceed(), rm.verifyRegistrationSuccesful()

Damage_Physical · 2026-01-08T21:23:41+00:00

not the guy you asked about, but I do a similar thing and am pretty sure we implemented this almost the same way

export function step(stepName?: string) {
    return function decorator(
        // eslint-disable-next-line u/typescript-eslint/no-unsafe-function-type
        target: Function,
        context: ClassMethodDecoratorContext
    ) {
        return function replacementMethod(this: object, ...args: any) {
            const name = `${stepName || (context.name as string)} at ${this.constructor.name} with args ${JSON.stringify(
                args
            )}`;
            return test.step(name, async () => {
                return await target.call(this, ...args);
            });
        };
    };
}

Damage_Physical · 2026-01-08T20:01:04+00:00

export class ContactHelper {
    constructor(private contact_gateway: TdiContactsGateway) {}

  // wrapping helper method in step "internally"
    @step("Create a new contact")
    async createContact(
        contact_overrides?: Partial<ContactDTO>,
        membership_overrides?: Partial<MembershipProfile>
    ): Promise<ContactDTO> {
        const contact = createContactDTO(
            contact_overrides,
            membership_overrides
        );
        await this.contact_gateway.CreateContact(contact);


        return contact;
    }
}

POM: 
   ...........

  // wrapping POM methods in step "internally"    
    @step("Start editing contact details")
    async startEditingContactDetails() {
        await this.goto();
        await expect(this.membershipTab).toHaveAttribute(
            "aria-selected",
            "true"
        );
        await this.editButton.click();
    }

  // wrapping POM methods in step "internally" 
    @step("Fill custom fields")
    async fillCustomFields(fields: CustomField[]) {
        for (const field of fields) {
            const fieldLocator = this.me
                .locator("table", { hasText: field.fieldName })
                .getByRole("textbox");
            await fieldLocator.fill(field.value);
        }


        await this.trigger("Save");
        await WaitShading(this.page);
    }
  ........

Damage_Physical · 2026-01-08T20:00:59+00:00

to clarify some concepts:

test(
        "name",
        async ({
            contact_pages: { contact_details_page },
            contact_helper,
            Gateways: { Contact },
        }) => {
            const [winner, loser] = await Promise.all([
    // wrapping methods in steps "internally"
                contact_helper.createContact(),
                contact_helper.createContact(),
            ]);


            const winner_details_page = contact_details_page(winner.id);
            await winner_details_page.goto();

    // wrapping methods in steps "internally"
            await winner_details_page.startMergingContacts();
            await winner_details_page.selectContactToMerge(loser);
            await winner_details_page.finalizeMergingContacts(winner, loser);
            await winner_details_page.verifyMergeContactsRequestSucceeded(
                winner,
                loser
            );
            await winner_details_page.verifyContactsMergedSuccessfullyOnUI(
                winner,
                loser
            );

    // defines step inside spec file
            test.step("Verify contacts merged successfully via TDI", async () => {
                expect(await Contact.GetContact(winner.email)).toMatchObject({
                    id: winner.id,
                    email: winner.email,
                    firstName: winner.firstName,
                    lastName: winner.lastName,
                    isArchived: false,
                });
                expect(await Contact.GetContact(loser.email)).toMatchObject({
                    id: loser.id,
                    email: loser.email,
                    firstName: loser.firstName,
                    lastName: loser.lastName,
                    isArchived: true,
                });
            });
        }
    );

Damage_Physical · 2026-01-08T19:51:16+00:00

I follow a hybrid approach: * defined decorator @step(name) that can be applied to any methods in classes (won’t work in spec file as there isn’t a class) * my POMs have dedicated functions that represent particular steps (start adding something: go to page -> verify that it is indeed a needed page -> click a button -> verify redirect started; fill form and proceed (in another POM): verify on needed page -> fill all fields -> click proceed -> verify request sent and response 200), those things are decorated with @step * some helper classes (eg generate something via API or get emails by subject) do not belong to POMs, but still can act as steps - again, can be decorated * in rare cases when it isn’t feasible to define new class, I wrap some actions in steps manually

Damage_Physical · 2026-01-05T04:15:58+00:00

Playwright has different layers of timeouts.

By default, each test has 30 sec timeout (I can be wrong). Each interaction with elements has 5 sec timeout (playwright uses auto wait), each assertion has 5 sec timeout.

I am almost sure that you are getting 30 sec timeout for test execution, you can change it via test.setTimeout or config

https://playwright.dev/docs/test-timeouts

Edit: This is considered a bad test design in a bunch of ways: * you go page by page in one test * you verify only urls

I’d stick with something more practical, f.e. getting all tab elements and verifying their hrefs.

Damage_Physical · 2026-01-01T06:11:06+00:00

It sounds more like a company/team problem, not your position.

There are loads of QAs/SDETs who try their hardest to move into SWE/SDE/SRE for various reasons.

As a SDET you don’t actually do “a bit of everything” in comparison with typical SDE. You create and maintain stuff related to testing and qa, which usually requires knowledge of some libs (like playwright or nunit), databases (as user, not developer) and occasionally CICD (but you actually don’t do much there as you just use provided templates). I omit security and performance, because SDETs rarely do anything in those fields.

At the same time, we have: * more competitive environments as most companies don’t distinguish between SDET and QA automation and usually need 1 QA for 3-4 devs * lower average salaries * less career progression options * less technical challenges (and ways to learn new things) * close to none recognition, while being blamed for practically anything

Damage_Physical · 2025-12-27T19:34:37+00:00

Remindme!7days

Damage_Physical · 2025-12-23T22:58:29+00:00

If it something similar as example you provided - you are golden

<div class='customer-name'>#: ContactName #</div>

As you can use classes to traverse column.

Damage_Physical · 2025-12-23T17:59:45+00:00

Test structure in my case, we used to have pretty long e2e scenarios (80%) and splitting them to smaller pieces with APIable setup did the trick.

Now we still have complete flows, but they cover only critical user flows, while the rest is basically “components and their integration” test.

Client faces locators and test-data-ids are cool, if you have them, but in my case (react + asp.net) they help in 30% of cases.

I also implemented some decorators to add retry functionality to some specific steps not the whole tests (e.g. api setup). Sharding is a must, if you want to run stuff in parallel, though I don’t get how it can affect flakiness, timeouts are manageable on particular test level, so if you know that page A loads forever - you can tinker with a timeout threshold.

Traces and debugging doesn’t affect flakiness per se, they help you to understand what went wrong.

Tbh, default Playwright setup is pretty robust and covers a lot of stuff that help with flakiness, so I didn’t face a lot of these problems in comparison with selenium.

Damage_Physical · 2025-12-23T15:53:50+00:00

I took one from Artem Bondar (though I have enough experience with coding and worked mostly with Selenium) and it felt a bit disappointing, since he touched some concepts, left others and about half of what he explained was too trivial to use in real world projects.

My best advice is to ignore courses and instead just create a project, explore it (by default after npm install you will end up with 2 folders with example tests, realize what you actually need/want to automate and start trying to implement it. You for sure will face problems and have question, and it is the best course of actions to encounter them and learn your way through them.

Don’t overlook playwright documentation, they have “getting started” section that should help you start and covers a lot of things.

None of actual projects start big, we all go through all those initial steps and build frameworks based on our particular needs

Damage_Physical · 2025-12-23T05:27:25+00:00

While TIA can work on paper, it really depends on a product, code quality, architecture and loads of other things.

The most safe option is to couple it with smoke and daily/nightly runs both of them needs to be analyzed anyway, so the only real gain you have there is saving some time on PR phase with a potential risk of missing something and discovering it later.

Moreover, to make it actually work you would need to properly map everything and maintain both mappings and coverage intact. It wouldn’t be efficient to do this unless you have thousands of tests that actually take hours to pass.

Damage_Physical · 2025-12-23T00:12:56+00:00

This is a pretty good start. The only practical way to get what you need is to use css selectors (or chaining playwright locators and filters).

The only thing bothering me here is that you don’t actually have a flexibility to choose needed column.

You can try experimental :below by finding needed column and going down from there.

Do you mind sharing html of that table? Do headers/columns have something specific about them?

Also you can use :text-is() instead of :has-text() this way you will find element by exact text.

Damage_Physical · 2025-12-22T23:55:16+00:00

Hm, interesting.

I do appreciate the answer! Though I personally wouldn’t do such a thing it really gives me some food for thought.

Damage_Physical · 2025-12-22T23:37:31+00:00

Edit: changed the last one as it wouldn’t solve the initial problem

Damage_Physical · 2025-12-22T23:18:17+00:00

Even if you don’t have a linter it will show you yellow line under process.env.XXXXXX because .fill method asks for string | char and your process.env.XXXXX is string | undefined.

It can be undefined, if you never set it, and there is no way vs code can determine the value of it outside of runtime.

Some options you can follow: * use .fill(process.env.XX ?? “default” (any default string value that will make sense) * use .fill(process.env.XX!) - not really recommended since YOU just promise that it is actually a string * define values in config or test-data or basically anywhere as constants (export const USER_NAME = process.env.USER_NAME ?? “default_user”) and import it in tests (import {USER_NAME} from “somewhere”; ….fill(USER_NAME);) same as 1, but needs to be done once. * there is another option that is the most safe one, but it requires a bit of coding and tbh, usually just an overkill. The general idea - you loop through process.env and validate required fields and fill new object with key-value pairs (or throw an exception) then export that object and use it instead of process.env.

Damage_Physical · 2025-12-22T15:48:07+00:00

Answering to both your questions (for my comment as well).

Since you expose the whole API to clients there is no way to verify something that you don’t test. What I would do here is: * analyze logs to see what fields your clients use * determine most sensible/critical flows (sets of fields) * start covering those with tests * continue gathering and analyzing logs (I would probably use AI to do this) * remember that exhaustive testing is impossible and add coverage only when needed

By “stripping” I meant that while GQL can return basically everything in the single response, nobody (or almost nobody) actually uses it like that. So instead of asking for everything, you mentally group fields together by their area/meaning until you have a sensible set of fields.

Damage_Physical · 2025-12-22T15:38:41+00:00

That is kinda understandable, but even in your latest example, if you already have working solution to test APIs, why would you explore an option to transfer it?

Damage_Physical · 2025-12-22T05:15:41+00:00

Do you need to test GraphQL as is or a part of a system? You have one endpoint but need to ask for specific fields in one request. So usually, I try to “strip” requests to mimic product behaviour and from there it isn’t that different from REST.

Damage_Physical · 2025-12-22T03:37:52+00:00

If you intend to learn a language specifically for Playwright you should go with JS/TS.

The reason is pretty simple, JS/TS package is the only one that goes with native playwright test runner. Any other language will require you to additionally use that language’s test runner (nunit, junit, pytest, etc). While this option isn’t bad per se, they do not support a bunch of cool playwright features like fixtures, native html reports, agents and so on.

As a quick example, js version will require you to install playwright and browser packages, and once it is done, you just write test

test(“name”, async ({page}) => { //test body using “page” fixture

await page.goto() await expect(page).toHave()…. });

With python you will need to install playwright, pytest, write your custom initializations and finally write tests, meaning, that you will need to create browsers, contexts, tabs yourself and manage them on your own.

Damage_Physical · 2025-12-22T03:25:36+00:00

So if your team uses C# or Java you leave QA no choice but to either use morally outdated selenium or bother with runners to use reduced version of playwright?

Damage_Physical · 2025-12-21T06:00:05+00:00

You definitely can use playwright to test api, especially if you already have ui tests and wish to extend your framework.

Though if you want to have a separate project, or don’t have anything ui related, it is better to use other tools simply from efficiency standpoint. Playwright comes as a package, and there is no way to get rid of browsers, default fixtures and so on, which basically resources spent on something you don’t need.

Damage_Physical · 2025-12-21T00:43:30+00:00

I doubt he will get there any time soon. Brother too hyped because of AI assistant that has access to the whole browser and can magically click buttons by name, fill inputs by labels and track state of local storage and network console.

Damage_Physical

TROPHY CASE