I’ve been writing test scripts using Playwright JS and have almost completed the full test suite—still learning along the way! Right now, I’m in the process of rechecking and updating my test scripts, and I have a doubt about structuring them properly.
However, my test case document has more detailed cases since UI checks are separate cases there. My confusion is about structuring these tests efficiently.
For example, when testing the “Forgot Password” flow, I included the UI validation of the FP page, email input, and email reception verification all in a single test script. This makes execution smoother, but it deviates from the test case document, where each check is a separate case.
My questions:
Should I strictly follow the test document and create a separate test for each verification?
Is it a good practice to combine UI checks along with functional steps, or should UI tests be completely separate?
What’s the best way to structure test scripts for better organization and maintainability?
Would love to hear how you structure your Playwright tests!
I would like to know are you using any framework in Playwright with JS.
Because my team uses Cucumber framework and in that it is quite easy to maintain test in the form of scenarios.
Or are you writing just script using JS in playwright for automation.
I would suggest to keep UI checks and functional checks seprately and the reson why I’m saying is this because on most occasions there might be issue in either of them, but due to single test case it might be blocked or marked as failed.
Keeping the test cases separately helps you in bifurcating the cases and you can easily manage them.
Apart from that better way to write test scripts is to develop framework, because as you said you are writing JS Script directly so it will get lengthy as you cover more features and functionality, and after a while it will be difficult for you to manage them.
Lastly, if this is your own project or side-project then don’t restrict yourself to test document. Tbh, test cases are not an evidence that testing is done properly.
Instead of that explore edge cases, corner cases and write scripts for that. That will be beneficial.
Documents are helpful but that depends on time, how much time you can allocate it, if your primary goal is practicing automation then keep the document as secondary.
This is a great question. I think you’re off to a good start, and it’s great that you’re already thinking of how to do things even better.
As a general guideline, I would ask what you’re trying to achieve, and how you’re likely to run the tests. Do you want to verify entire flows? Do you want feedback on specific parts of the functionality? Do you want to be able to just check UI elements in isolation?
Additionally, is it possible to do your test set up in another way? For example, if you want to focus on UI flows and are particularly interested in whether the email is received, is it even possible for you to trigger the email being sent without going via the UI? If not, then there’s little value in creating a separate test which would duplicate previous tests, then add one extra assertion. Both would fail if there’s an issue in the set up. But if it is possible, then you could have a test of the trigger via the UI, and a separate test for the email, triggered by API, for example. In this case, the tests would fail for different reasons, so it would make sense to have them both.
