Hooks and Tags Interview Questions in Cucumber

Introduction

Hooks and tags are two of the most important Cucumber topics for automation interviews because they show whether a candidate understands real framework control, not only feature file syntax. A tester may know how to write Given, When, and Then steps, but enterprise automation needs more than readable scenarios. It needs clean setup, reliable teardown, screenshot capture, test filtering, selective execution, environment control, and CI/CD-friendly grouping. Hooks and tags provide much of that control.

Hooks are special methods that run automatically before or after scenarios. They are not written directly inside the feature file steps, but Cucumber executes them based on hook annotations and optional tag conditions. Tags are labels added to features or scenarios to classify tests. They help teams run smoke tests, regression tests, API tests, UI tests, module-specific tests, critical tests, and environment-specific tests without editing the scenario body.

In interviews, hooks and tags are usually asked together because they are connected in practical framework design. Hooks manage setup and cleanup. Tags decide which scenarios belong to which category. Tagged hooks combine both ideas by running setup or cleanup only for scenarios that carry a specific tag. For example, a browser setup hook may run only for @UI scenarios, while an API token setup hook may run only for @API scenarios.

A strong answer should go beyond definitions. You should explain why hooks keep step definitions clean, why tags make execution flexible, how hook order works, how tag expressions are used, how screenshots are captured, and how both are used in CI/CD pipelines. This article gives paragraph-based, interview-ready explanations so you can answer both basic and real project questions confidently.

What Are Hooks in Cucumber?

Hooks in Cucumber are methods that execute automatically before or after scenarios. They allow the framework to run common setup and cleanup logic without writing that logic in every scenario or every step definition. Hooks are usually written in Java classes under a hooks package and annotated with Cucumber annotations such as @Before and @After.

The most common use of a hook is browser management. Before a UI scenario starts, the framework may launch the browser, maximize the window, load configuration, initialize page objects, and prepare reporting. After the scenario ends, the framework may capture a screenshot if the scenario failed, attach logs to the report, close the browser, and clean up test data.

@Before
public void setup() {
    // initialize browser, config, reports, or context
}

@After
public void tearDown() {
    // capture evidence, cleanup data, close browser
}

Hooks are not business steps. They should not describe user behavior such as placing an order, approving a payment, or updating a customer. Those actions belong in Gherkin steps and step definitions. Hooks should handle technical lifecycle tasks that must happen around scenario execution.

Why Do We Use Hooks?

Hooks are used to centralize repeated setup and cleanup work. Without hooks, every scenario or step definition might repeat code to open the browser, load the URL, initialize reports, close the driver, or clean test data. That duplication makes the framework harder to maintain. If the browser setup changes, many files may need updates. Hooks solve this by keeping common lifecycle behavior in one place.

Hooks also keep step definitions cleaner. A step definition should map business-readable Gherkin to automation code. It should not be responsible for every technical setup activity. When hooks initialize the browser and context before the scenario starts, step definitions can focus on the behavior under test.

Another reason hooks are important is reliability. After hooks ensure cleanup runs even when a scenario fails. For example, if a test fails in the middle of checkout, the after hook can still capture a screenshot, attach logs, and close the browser. This prevents leaked browser sessions and preserves failure evidence.

In interview terms, you can say that hooks improve reusability, maintainability, consistency, and framework cleanliness by separating setup and teardown logic from scenario steps.

Difference Between Before and After Hooks

The @Before hook executes before each scenario, while the @After hook executes after each scenario. A before hook is mainly used for setup. An after hook is mainly used for cleanup and failure evidence. Both hooks can run for every scenario or only for scenarios with matching tags.

In real projects, before hooks usually initialize WebDriver, browser options, API clients, database connections, scenario context, logging, and reporting. After hooks usually capture screenshots, attach evidence, close resources, reset data, and clear context. This lifecycle makes scenario execution predictable.

Can We Have Multiple Hooks?

Yes, Cucumber allows multiple before hooks and multiple after hooks. This is useful when setup is divided into smaller responsibilities. For example, one before hook may load configuration, another may initialize reporting, and another may launch the browser. However, multiple hooks should be used carefully. Too many hooks can make execution flow difficult to understand.

Cucumber supports hook ordering through the order attribute. For before hooks, lower order values execute first. For after hooks, higher order values execute first. This allows teams to control setup and cleanup sequence.

@Before(order = 1)
public void loadConfig() {
}

@Before(order = 2)
public void startBrowser() {
}

@After(order = 2)
public void captureEvidence() {
}

@After(order = 1)
public void closeBrowser() {
}

The ordering is important when one action depends on another. Configuration should load before browser creation. Screenshot capture should happen before the browser is closed. Cleanup should happen after useful evidence is captured. A good framework keeps hook order simple and documents it clearly.

What Is Hook Execution Order?

Hook execution order decides the sequence in which multiple hooks run. For @Before hooks, the hook with the lower order value runs first. For example, @Before(order = 1) runs before @Before(order = 2). This makes sense because setup usually moves from general preparation to specific initialization.

@Before(order = 1) -> runs first
@Before(order = 2) -> runs second

For @After hooks, the order is reversed. The hook with the higher order value runs first. For example, @After(order = 2) runs before @After(order = 1). This is useful because cleanup often needs to undo setup in reverse order. If the browser was launched after configuration was loaded, screenshot capture and browser cleanup should happen before final context cleanup.

@After(order = 2) -> runs first
@After(order = 1) -> runs second

In interviews, do not just memorize the rule. Explain why it matters. If a browser is closed before screenshot capture, failure evidence is lost. If test data is deleted before validation logs are collected, debugging becomes harder. Hook order supports reliable setup and teardown.

What Is a Tagged Hook?

A tagged hook is a hook that runs only for scenarios or features with a matching tag. This is one of the most useful Cucumber framework features because not every scenario needs the same setup. A UI scenario may need a browser. An API scenario may need an authentication token. A database scenario may need a database connection. Running all setup for every scenario wastes time and creates unnecessary dependencies.

@Before("@UI")
public void setupBrowser() {
    // runs only for @UI scenarios
}

@Before("@API")
public void setupApiClient() {
    // runs only for @API scenarios
}

Tagged hooks help keep execution efficient. If a scenario is tagged @API, the framework does not need to launch a browser. If a scenario is tagged @UI, it may not need API-specific setup unless the scenario also carries an API-related tag. This selective setup becomes very important in large automation suites.

In interviews, you can say that tagged hooks are used for conditional setup and cleanup based on scenario tags. They are commonly used for browser setup, API setup, mobile setup, database cleanup, environment-specific preparation, reporting, and module-specific initialization.

What Is the Scenario Object in Hooks?

Cucumber provides a Scenario object that can be passed into hooks. This object gives access to scenario information such as the scenario name, status, tags, and failure state. It is commonly used in after hooks to check whether a scenario failed and then capture screenshots or attach logs.

@After
public void afterScenario(Scenario scenario) {
    if (scenario.isFailed()) {
        // capture screenshot and attach evidence
    }
}

The Scenario object is useful because hooks run outside the Gherkin steps. The hook still needs to know which scenario is running and whether it passed or failed. With the Scenario object, the framework can attach relevant evidence to the correct scenario in the report.

In modern Cucumber reports, attachments can include screenshots, text logs, JSON evidence, API response snippets, or other debugging information. This makes the report more useful than a simple pass/fail summary.

How Do You Capture Screenshots in Hooks?

Screenshots are usually captured inside an @After hook when a scenario fails. The flow is simple: check whether the scenario failed, take a screenshot using Selenium's screenshot API, and attach the screenshot to the Cucumber report. This ensures every failed UI scenario has visual evidence.

@After("@UI")
public void captureScreenshotOnFailure(Scenario scenario) {
    if (scenario.isFailed()) {
        byte[] screenshot = ((TakesScreenshot) driver)
            .getScreenshotAs(OutputType.BYTES);
        scenario.attach(screenshot, "image/png", scenario.getName());
    }
}

The screenshot should be captured before the browser is closed. This is why hook order matters. If one after hook closes the browser first, the screenshot hook will fail or capture nothing. A clean design uses ordered hooks so screenshot capture happens first and browser cleanup happens later.

Screenshots are especially useful for Selenium tests because they show the page state at the time of failure. They can reveal validation messages, loading indicators, popups, wrong pages, blocked clicks, overlays, or missing elements. In reports, screenshots reduce the need to rerun failed tests immediately.

What Should Not Be Written Inside Hooks?

Hooks should not contain business logic. A hook should not place an order, approve a loan, update a customer, submit a payment, or verify a business rule. These actions belong in scenarios and step definitions because they are part of the behavior being tested. If business behavior is hidden inside hooks, the feature file becomes misleading.

Hooks should also avoid assertions that decide the business result of a scenario. Assertions belong in Then steps or validation services called by Then steps. A hook may verify technical cleanup or capture evidence, but it should not quietly perform the main test validation outside the scenario.

Another mistake is placing too much feature-specific setup in global hooks. If only one module needs a special dataset, that setup should be explicit or controlled by tags. Global hooks should remain lightweight and broadly applicable. Heavy hooks slow down the entire suite and make failures harder to debug.

A practical rule is this: hooks should handle technical lifecycle concerns, while feature files and step definitions should handle business behavior.

What Are Tags in Cucumber?

Tags in Cucumber are labels placed above features, scenarios, scenario outlines, or examples. They begin with the @ symbol and classify scenarios for execution, reporting, organization, and conditional hooks. Common tags include @Smoke, @Regression, @API, @UI, @Critical, @Login, and @Payment.

@Smoke
@Login
Scenario: Successful login with valid credentials
  Given the user has valid credentials
  When the user logs in
  Then the user should see the dashboard

Tags do not change the meaning of the scenario. They classify it. A scenario tagged as smoke can be selected for a quick build verification run. A scenario tagged as regression can be included in a larger nightly suite. A scenario tagged as API can trigger API-specific hooks or be executed in API-only pipelines.

Tags can also be applied at feature level. When a tag is placed above a Feature, all scenarios inside the feature inherit that tag. This is useful when every scenario in a file belongs to the same module or execution category. However, feature-level tags should be used carefully because they apply broadly.

Why Do We Use Tags?

Tags are used to organize and selectively execute scenarios. Without tags, running specific subsets of tests becomes difficult. A team may need to run only smoke tests after every commit, only payment tests after a payment service change, only API tests in a backend pipeline, or only critical tests before release. Tags make this selection possible.

Tags also support reporting. Reports can show which categories passed or failed. If all @Payment scenarios fail, the team can quickly identify a module-level issue. If only @Chrome tagged scenarios fail, the issue may be browser-specific. Meaningful tags improve result analysis.

Tags support hooks as well. A hook can run only for scenarios with a matching tag. For example, @Before("@UI") can launch the browser only for UI scenarios. @Before("@API") can prepare API authentication only for API scenarios. This keeps setup efficient.

In CI/CD, tags are essential. Pipelines can run fast smoke suites for pull requests, full regression suites nightly, module-specific suites after targeted changes, and critical suites before releases. Tags allow this flexibility without changing feature files.

Can Multiple Tags Be Added?

Yes, a scenario can have multiple tags. This is often the best way to classify a scenario because each tag can represent one idea. For example, a login smoke test for the UI layer may use @Smoke, @UI, and @Login. A critical payment API scenario may use @Regression, @API, @Payment, and @Critical.

@Smoke
@UI
@Login
Scenario: Successful login
  Given the user has valid credentials
  When the user logs in
  Then the login should be successful

Multiple simple tags are better than one large combined tag. For example, @Smoke, @UI, and @Login are clearer than @SmokeUILoginTest. Simple tags can be combined flexibly using tag expressions. Large combined tags are harder to reuse.

However, too many tags can create clutter. Use tags that support execution, reporting, ownership, module grouping, priority, environment, or hook control. Avoid temporary tags, personal tags, unclear tags, and duplicate tags with the same meaning.

Can Tags Be Added at Feature Level?

Yes, tags can be added at feature level. A feature-level tag applies to every scenario in that feature file. This is useful when all scenarios belong to the same module or test category. For example, a login feature may have a @Login tag at the feature level, and individual scenarios may add @Smoke or @Regression tags as needed.

@Login
Feature: Login

@Smoke
Scenario: Successful login
  Given the user has valid credentials
  When the user logs in
  Then the user should see the dashboard

In this example, the scenario effectively has both @Login and @Smoke. Feature-level tags reduce repetition, but they must be used carefully. If only some scenarios belong to a category, use scenario-level tags instead. Otherwise, tag inheritance may cause unexpected execution.

Interviewers may ask this to check whether you understand tag inheritance. A good answer is: yes, feature-level tags are inherited by all scenarios in that feature, so use them only when the tag applies to every scenario.

What Are Tag Expressions?

Tag expressions allow teams to combine tags using logical operators such as and, or, and not. They make execution flexible. Instead of creating separate runners for every possible suite, the framework can select scenarios dynamically using tag expressions.

@Smoke and @Login
@Smoke or @Regression
not @WIP
(@Smoke or @Critical) and @UI

The and operator means the scenario must contain all specified tags. The or operator means the scenario can contain any of the specified tags. The not operator excludes scenarios with a specific tag. Parentheses can group expressions when logic becomes more complex.

Tag expressions are commonly configured in the runner class, Maven command, Gradle command, TestNG XML, JUnit platform configuration, or CI/CD pipeline variables. They allow the same feature files to support different execution strategies.

Difference Between And, Or, and Not in Tag Expressions

The and operator is used when a scenario must match all listed tags. For example, @Smoke and @Payment runs only scenarios that are both smoke tests and payment scenarios. If a scenario has only @Smoke but not @Payment, it will not run.

The or operator is used when a scenario can match any listed tag. For example, @Smoke or @Regression runs scenarios tagged either smoke or regression. This is useful when you want to combine different groups into one run.

The not operator excludes scenarios. For example, not @WIP runs all scenarios except those tagged as work in progress. This is useful when incomplete or unstable scenarios exist in the codebase but should not run in normal pipelines.

How Do You Execute Only Smoke Tests?

To execute only smoke tests, tag the required scenarios with @Smoke and configure the runner or command to include that tag. Smoke tests are usually a small set of critical scenarios that verify whether the application is stable enough for deeper testing.

@CucumberOptions(
  tags = "@Smoke"
)

In CI/CD, smoke tests often run after every commit, pull request, or deployment to a test environment. They provide quick feedback. A smoke suite should be fast, stable, and focused on critical flows. It should not include every edge case or long end-to-end regression test.

How Do You Execute Smoke or Regression Tests?

To execute scenarios that are either smoke or regression, use the or operator. The expression @Smoke or @Regression includes scenarios that have either tag. This is useful when a pipeline needs to run more than one category without requiring every scenario to have both tags.

tags = "@Smoke or @Regression"

Use this expression when you want a broad selection. If a scenario has only @Smoke, it runs. If it has only @Regression, it also runs. If it has both, it runs as well. This is different from and, which requires both tags on the same scenario.

How Do You Execute Smoke and Login Tests?

To execute only scenarios that are both smoke tests and login tests, use @Smoke and @Login. This filters the execution to a specific intersection of categories. It is useful when a team wants to run a focused set, such as login smoke tests, payment smoke tests, or API critical tests.

tags = "@Smoke and @Login"

This expression will not run every login test. It will not run every smoke test. It will run only scenarios that contain both tags. This is a common interview scenario because it checks whether the candidate understands the difference between broad grouping and precise filtering.

How Do You Exclude Regression Tests?

To exclude regression tests, use the not operator. For example, not @Regression runs scenarios that do not have the regression tag. This can be useful when running a quick suite that should avoid long-running regression scenarios.

tags = "not @Regression"

Exclusion tags should be used carefully. If too many scenarios are excluded through complex expressions, it may become difficult to understand what is actually running. Keep tag expressions readable and document important CI/CD execution rules.

Difference Between Hooks and Tags

Hooks and tags solve different problems. Hooks execute code. Tags classify scenarios. A hook is written in Java and runs before or after a scenario. A tag is written in a feature file and marks a feature or scenario for grouping, filtering, reporting, or conditional execution.

They become connected through tagged hooks. A tagged hook is still a hook, but its execution depends on a tag. For example, @Before("@API") is a hook that runs only for scenarios tagged @API.

Common Tag Naming Conventions

Good tag names are meaningful, consistent, and purpose-driven. Common execution tags include @Smoke, @Regression, and @Sanity. Technology tags include @UI, @API, @Mobile, and @Database. Module tags include @Login, @Payment, @Order, and @Customer. Priority tags include @Critical, @High, @Medium, and @Low.

Consistency matters because Cucumber tags are case-sensitive. If one scenario uses @Smoke and another uses @smoke, they are different tags. This can cause execution problems. Teams should document standard tags and avoid duplicate meanings such as @Smoke, @SmokeTest, and @SmokeTesting.

Use multiple simple tags rather than one combined tag. @Smoke @UI @Login is better than @SmokeUILoginTest. Simple tags are easier to filter, combine, and maintain.

How Are Tags Used in CI/CD?

Tags are extremely useful in CI/CD pipelines because different pipeline stages need different test scopes. A commit pipeline may run only fast smoke tests. A pull request pipeline may run smoke tests plus affected module tests. A nightly pipeline may run the full regression suite. A release pipeline may run smoke, critical, regression, and cross-browser tests.

Commit Pipeline  -> @Smoke
Pull Request     -> @Smoke or @ChangedModule
Nightly Build    -> @Regression
Release Pipeline -> @Smoke or @Critical or @Regression

This strategy keeps feedback fast while still supporting deep validation at the right time. Running every test after every small commit may be too slow. Running only a few tests before release may be risky. Tags help balance speed and coverage.

CI/CD tools can pass tag expressions as parameters. This allows teams to change what runs without editing feature files or runner classes. A mature framework supports this kind of flexible execution.

Common Mistakes with Hooks

A common mistake is writing business logic inside hooks. Hooks should not complete workflows that belong in scenarios. Another mistake is launching multiple browsers by accident because more than one hook creates WebDriver. This can happen when global hooks and tagged hooks overlap without clear conditions.

Not closing the browser is another serious mistake. Browser processes can remain open and consume memory, especially in CI machines. After hooks should reliably close or quit drivers. If the test fails before cleanup, the after hook should still run and release resources.

Duplicate hooks can also create confusion. If several classes contain similar hooks, the execution order may be hard to understand. Teams should keep hook design centralized and readable. Hook ordering should be used only when needed and not as a way to hide complex dependencies.

Another mistake is capturing screenshots after quitting the driver. Screenshot capture must happen before browser cleanup. This is one of the most practical reasons interviewers ask about hook order.

Common Mistakes with Tags

The most common tag mistake is tag explosion. Some teams add too many tags to every scenario, such as smoke, regression, sanity, sprint number, release number, browser, environment, module, priority, owner, and temporary execution tags. Too many tags make scenarios noisy and hard to maintain.

Poor naming is another issue. Tags such as @Test, @Run, @Temp, or @Check do not explain why the tag exists. Tags should communicate purpose. A person reading the feature file should understand whether the tag is for execution, module grouping, priority, technology, or environment.

Duplicate tag meanings also create problems. If @Smoke, @SmokeTest, and @Sanity are used inconsistently for the same purpose, pipelines may miss scenarios. Teams should standardize vocabulary and clean tags regularly.

Using tags as configuration is also a mistake. Browser, URL, credentials, and test data usually belong in configuration files or test data sources, not tags. Tags classify tests. They should not become a replacement for environment configuration.

Best Practices for Hooks

Keep hooks lightweight and focused. A hook should perform setup, cleanup, logging, reporting, screenshot capture, browser management, API setup, or data cleanup. It should not become a large hidden workflow. If a hook is difficult to understand, split responsibilities or move business logic into proper scenario steps.

Use tagged hooks for conditional setup. Launch browsers only for UI scenarios. Prepare API clients only for API scenarios. Run mobile setup only for mobile scenarios. This improves execution speed and avoids unnecessary dependencies.

Use hook order carefully. Configuration should load before driver creation. Screenshots should be captured before browser closure. Cleanup should happen after evidence capture. Keep ordering simple enough that a new team member can understand the lifecycle quickly.

Centralize browser management. Do not create drivers randomly inside step definitions and hooks. Use a driver factory or similar design. For parallel execution, use thread-safe driver handling such as ThreadLocal. This prevents cross-scenario interference.

Best Practices for Tags

Use meaningful tags that serve a clear purpose. Good tag categories include execution type, technology layer, business module, priority, and environment. Examples include @Smoke, @Regression, @UI, @API, @Login, @Payment, and @Critical.

Choose one naming style and use it everywhere. Avoid mixing @Smoke, @smoke, and @SMOKE. Tags are case-sensitive, so inconsistent naming leads to missed executions and confusing reports.

Apply feature-level tags only when every scenario in the feature belongs to that category. Apply scenario-level tags for specific scenarios. Use multiple simple tags instead of large combined tags. Review tags regularly and remove unused or duplicate tags.

Keep tag expressions readable. Expressions such as @Smoke and @Payment are clear. Very long expressions with many nested conditions can become difficult to maintain. If a CI pipeline needs complex selection, document the purpose clearly.

Scenario-Based Interview Example

A common interview question is: How would you execute only payment smoke tests? The correct answer is to tag the relevant scenarios with both @Smoke and @Payment, then use the tag expression @Smoke and @Payment. This ensures only scenarios that belong to both categories run.

@Smoke
@Payment
Scenario: Successful card payment
  Given the customer has items in the cart
  When the customer pays using a valid card
  Then the payment should be approved

tags = "@Smoke and @Payment"

This answer shows that you understand multiple tags and logical filtering. If you used @Smoke or @Payment, the result would be broader. It would run all smoke scenarios and all payment scenarios, not only payment smoke scenarios.

Real Project Answer for Hooks

When asked how you used hooks in your project, give a practical answer. You can say that your framework used before hooks to load configuration, initialize WebDriver for UI scenarios, initialize REST Assured clients for API scenarios, create scenario context, and start reporting. You can say that after hooks captured screenshots for failed UI scenarios, attached logs, closed the browser, cleared context, and cleaned up test data.

You can also mention tagged hooks. For example, @Before("@UI") launched the browser only for UI scenarios, while @Before("@API") prepared API authentication only for API scenarios. This avoided unnecessary browser launch for API tests and made execution faster.

A strong project answer includes reliability. Explain that screenshot capture happened before driver quit and that reports were published after execution. Mention that hooks were kept lightweight and did not contain business logic. This shows framework maturity.

Real Project Answer for Tags

When asked how you used tags in your project, explain your tagging strategy. You can say that scenarios were organized using execution tags such as @Smoke, @Regression, and @Sanity; technology tags such as @UI and @API; module tags such as @Login, @Payment, and @Customer; and priority tags such as @Critical and @High.

Then explain CI/CD usage. For example, smoke tests ran after every commit, regression tests ran nightly, and release pipelines ran critical scenarios before deployment. Tag expressions allowed the team to execute specific combinations without modifying feature files.

This kind of answer is better than only saying "we used @Smoke and @Regression." Interviewers want to know why tags were used, how they supported execution, and whether the strategy was maintainable.

Interview-Ready Summary

Hooks are special Cucumber methods that execute automatically before or after scenarios. They are used for setup, cleanup, browser lifecycle management, report initialization, screenshot capture, logging, API setup, database setup, and test data cleanup. Before hooks usually prepare the scenario. After hooks usually capture evidence and release resources.

Tags are labels added to features or scenarios. They organize tests and support selective execution. Tags are used for smoke testing, regression testing, API testing, UI testing, module grouping, priority grouping, environment grouping, reporting, and CI/CD pipeline control. Tag expressions combine tags using and, or, and not.

Tagged hooks combine both concepts. They allow setup or cleanup to run only for scenarios with matching tags. This is useful for separating UI setup from API setup, controlling module-specific initialization, and keeping execution efficient.

The most important interview point is that hooks execute code, while tags classify scenarios. Hooks keep step definitions clean. Tags keep execution flexible. Together, they make Cucumber frameworks more maintainable, scalable, and CI/CD-ready.

Golden Rules

Use hooks only for technical setup, cleanup, evidence capture, and lifecycle management. Do not hide business logic or primary assertions inside hooks. Capture screenshots before closing the browser. Keep hook ordering simple and meaningful. Use tagged hooks when setup applies only to specific categories of scenarios.

Use tags that are meaningful and consistent. Separate execution type, technology, module, priority, and environment tags. Use multiple simple tags instead of one large combined tag. Avoid duplicate, temporary, personal, or vague tags. Review tags regularly so the test suite remains clean.

The final takeaway is simple: hooks control when framework code runs, tags control which scenarios belong to which groups, and tagged hooks connect both ideas for clean, flexible, enterprise-grade Cucumber execution.