test.describe(): Grouping Tests
test.describe() groups related test cases into a single block.
It acts as a test suite in Playwright.
A simple analogy is keeping similar items inside the same box or organizing a school timetable where Mathematics and Science are grouped separately.
Benefits
- Groups related test cases together.
- Organizes tests module-wise.
- Supports common hooks within the group.
- Improves readability.
- Improves maintainability.
- Produces better test reports.
Common Examples
- Login Tests
- Dashboard Tests
- Payment Module Tests
- User Management Tests
Supported Hooks Inside test.describe()
beforeAll()beforeEach()afterEach()
Real Project Usage
"In my projects, I use
test.describe()to organize automation module-wise, such as Login, Dashboard, and Payments. It helps group related test cases and apply common hooks across the entire module."
Hooks: test.beforeEach() and test.afterEach()
Hooks allow common setup and cleanup operations to run automatically before or after each test.
test.beforeEach()
Runs automatically before every test.
A simple analogy is a teacher giving the same instructions before every examination or washing your hands before every meal.
Typical setup activities include:
- Opening the application
- Navigating to the required page
- Logging into the application
- Preparing test data
Using beforeEach() eliminates repeated code inside every test case.
test.afterEach()
Runs automatically after every test finishes.
A simple analogy is putting toys back after playing or switching off the lights before leaving a room.
Typical cleanup activities include:
- Logging out
- Closing resources
- Clearing temporary data
- Resetting the application state
test.only(), test.skip(), and test.fixme()
Playwright provides several annotations to control test execution.
test.only()
Runs only the selected test while ignoring every other test.
A simple analogy is watching only one episode of a television series while skipping the rest.
This is commonly used during:
- Development
- Debugging
- Local execution
test.skip()
Skips a test intentionally.
A simple analogy is skipping a ride in an amusement park because it is temporarily unavailable.
Use test.skip() when:
- The feature is not ready.
- The test is not applicable.
- The environment does not support execution.
test.fixme()
Marks a test as known to be broken.
A simple analogy is a road under repair.
The test remains in the suite but is skipped until it has been fixed.
Difference Between skip() and fixme()
test.skip()
- Intentionally not executed.
- May run later.
test.fixme()
- Known broken test.
- Indicates the test requires fixing before execution.
Running a Single Test
Playwright provides multiple ways to execute an individual test.
Using test.only()
Most commonly used during development and debugging.
Running a Specific Test File
npx playwright test login.spec.ts
Running a Test by Name
npx playwright test --grep "Verify user login"
Real Project Usage
"During development, I usually execute individual tests using
test.only(). For larger executions, I run a specific test file or use--grepto execute tests matching a particular name."
Running Tests in Parallel
Playwright supports parallel execution by default using multiple workers.
Tests are automatically distributed across available workers and executed simultaneously.
Simple Analogy
Imagine a bank.
- One counter serves customers one after another (Serial Execution).
- Multiple counters serve customers simultaneously (Parallel Execution).
Playwright workers behave like multiple bank counters.
Example
workers: 4
This configuration allows four tests to execute simultaneously.
Benefits
- Faster execution
- Better utilization of system resources
- Reduced regression execution time
Controlling Parallel Execution
Parallel execution can be controlled in multiple ways.
Configure Workers
Specify the required number of workers.
Example:
workers: 3
This executes three tests simultaneously.
Serial Execution
When tests depend on each other, use:
test.describe.serial()
This forces the tests to execute one after another.
Command-Line or Configuration
Parallel execution can also be controlled through:
- Playwright configuration
- Command-line options
Real Project Usage
"For dependent scenarios, I reduce the number of workers and move those test cases into
test.describe.serial()blocks to avoid execution conflicts."
Banking Application Example
- Transaction-related tests execute serially because they depend on previous transactions.
- Independent modules execute in parallel for faster regression execution.
Retrying Failed Tests
Playwright supports retrying failed tests using the retries configuration.
Retries are mainly intended for handling temporary failures such as:
- Network delays
- Timing issues
- Temporary environmental problems
Interview Answer
"In Playwright, failed tests can be retried by configuring the
retriessetting either globally in the configuration file or during execution through the command line."
Retries should only handle flaky or temporary failures.
A genuine application defect will continue failing even after multiple retries.
FAQs
What is test.describe()?
test.describe() groups related test cases into a test suite, allowing better organization, shared hooks, and improved reporting.
What are beforeEach() and afterEach()?
These are Playwright hooks that execute automatically before and after every test.
They are commonly used for:
- Test setup
- Navigation
- Login
- Cleanup
What is the difference between test.skip() and test.fixme()?
test.skip() intentionally skips a test.
test.fixme() marks a known broken test that requires fixing before execution.
How do you run a single test?
You can execute a single test using:
test.only()npx playwright test <filename>--grep "<test name>"
How does Playwright execute tests in parallel?
Playwright distributes tests across multiple workers and executes them simultaneously.
The number of workers is controlled using the workers configuration.
When should test.describe.serial() be used?
Use test.describe.serial() when test cases depend on one another and must execute in a specific order.
Examples include banking transaction workflows.
How do you retry failed tests?
Configure the retries option either in the Playwright configuration file or through command-line execution.
Retries are useful for temporary or flaky failures but should not be used to hide genuine defects.