Add new "noConditionalInTest" rule

[ozyx]

Closes #58

Description:

Adds a new rule to disallow conditional statements such as if, switch, and ternary expressions within tests. Adapted from this eslint-plugin-jest rule and modified for Playwright.

[ozyx]

Thanks!

[bennettdams]

How do you work with null-safety in tests now? Here is a basic example, I get some data from the API and want to use the reponse data to check if something is visible in the UI:

test("shows car info", async ({ page }) => {
  // ...
  const carId = "123"
  const carFromAPI: { carId: string; name: string } | null = await apiGET(`cars/${carId}`, page);

  expect(carFromAPI, "Has car from API").toBeDefined();

  // I know `carFromAPI` is defined here because if the `expect` before - the `if` is just there to make TypeScript happy.
  if (carFromAPI) {
    expect(carFromAPI.carId, "Car ID in UI matches API").toBe(carId);

    await expect(pageContent.locator(`'${car.name}'`), "Car name visible").toBeVisible();
  }
  // ...
})

In such scenarios where I know a variable is defined from the expect, I still use ifs to make TypeScript happy.

Is there a better way? I mean, I also show linting errors for non-null assertions, so that wouldn't help either.

[mskelton]

Why does it return null? Could you have apiGET throw an error?

[bennettdams]

@mskelton apiGET is just a small helper function:

export async function apiGET<TData>(
  apiRoute: string,
  page: Page
): Promise<TData> {
  const response = await page.request.get(`${BASE_URL}/my-api/${apiRoute}`);
  await expect(response, "API response is OK").toBeOK();
  return await response.json();
}

If you want to throw in that function, you'd still need a conditional check (e.g. if(response.body === null) throw new Error()), so you basically shifted the conditional check from your test to the inner function. Mabye I misunderstand the reasoning of this rule, but this would just help with fixing the lint warning, instead of fixing the problem, no?

[mskelton]

You could use Node's assert function which will assert the value is true and TypeScript will then understand that all future usages are non-null.

[bennettdams]

@mskelton Thanks, that works great, even though I still have the feeling that this is only a way to get rid of the lint warning, instead of taking care of the problem.