The web app I’m automating through playwright has a lengthy task creation form with almost 17 inputs fields of different types.
Currently we have implemented automation on it by filling all the fields and then transition the task through its statuses. All in 1 test. This operation takes 60 seconds at maximum.
I was wondering if there is another better practice to follow in such a scenario?
My opinion is that while performing actions like transitioning could be done in separate tests, the part where you need to check if all fields of a lengthy form were filled in correctly and their data is displaying properly, will surely have to be done in one lengthy test.
I think that sometimes you just have to grit your teeth and do the thing. In a “happy path” test where you want valid inputs, verify those inputs are still displayed and then a submission. you might just have to deal with it.
But for other things such as “every input is correct, except for one” to validate error handling and messaging you might use a different tool or technique to make the test data driven. like submit the data as an api call (mocking) and then render the response as a page? Mock APIs | Playwright
If the goal of the test is to render the result in the different “status of the task” then that mocking should also be useful.
Then you can eliminate the “stuff we dont care about for this test” like the entry of the data in all the fields.
PS - if the application itself makes the mocking tactic impossible, I’d work with dev to see if there was a way we could adjust the application to allow the tactic