Hi all, I am looking for guidance regarding best practice.
How many tests should be in a test file (.spec)?
My colleagues and I are trying to determine the best practice around number of tests per test file (.spec).
My opinion is one test per test file (.spec). The reason being is,;
- This is a smaller code base per file which makes maintenance easier.
- Each test file (.spec) can be ran in isolation. 3 Each test file (.spec) can set up and tear down the test data it requires to perform the test.
Please give me you opinion, advise and feedback regarding the number of tests per file (.spec).
This thread is trying to answer question "What is the best practice for the number of tests per test file (.spec)?"
Hi, having small ('it fits in your head') source files is always a good idea. But the answer to 'how small to keep them' is: 'it depends'.
If the tests are all really closely related, for example all variations of tests for one component, and if it doesn't become unwieldy, then it can be OK to put them all together.
The argument for set up and tear down can be countered, because fixtures enable each test to take care of their own setup and teardown in isolation, even in the same .spec file.
I don't have a specific number; for me the answer is also "it depends". I like to group related tests together logically in the same file. My criteria for splitting up one spec into multiple is based on the following:
- given the number of lines of code how annoying is it to scroll or use my IDE to find what I need?
- how likely is it for this file to be touched frequently enough to cause merge conflicts?
- how long does it take this spec to run, and when I do the math is it going to make my entire test run take longer than reasonable given the number of workers used?
- do I need common setup/teardown or helper methods for multiple tests where I'd rather just keep them all in the same spec instead of create a new class?
Related Discord Threads
Rayrun is a community for QA engineers. I am constantly looking for new ways to add value to people learning Playwright and other browser automation frameworks. If you have feedback, email [email protected].