Session 44 - Selenium with Java | TestNG | Dependency Methods | Grouping Tests

Main ideas / lessons conveyed

1) TestNG Dependency Methods (dependsOnMethods)

Problem with default TestNG behavior

• By default, TestNG runs every method annotated with @Test in a class.
• If an early “setup” test fails (e.g., openApp), dependent later tests (e.g., login, search, etc.) will logically fail too—but TestNG will still attempt to run them, wasting time.

Goal

• If a dependency test method fails, then methods that depend on it should be skipped, not executed.

Concept of dependencies

Example dependency chain:

• login depends on openApp
• search and advancedSearch depend on login
• logOut depends on login

Methodology / implementation steps shown (practical approach)

• Create a TestNG class containing multiple @Test methods (e.g., openApp, login, search, advancedSearch, logOut).
• Assign priority values (used for ordering, though dependency controls skipping/execution).
• Demonstrate behavior using assertions:
  • A failing assertion in a dependency method represents “dependency failed”.
• Add dependency control:
  • For login, set in @Test:
    • dependsOnMethods = {"openApp"}
  • For dependent methods:
    • search depends on login
    • advancedSearch depends on login
    • logOut depends on login

Expected outcomes

• If openApp fails → login (and its dependents) are skipped.
• If openApp passes but login fails → search, advancedSearch, logOut are skipped.

Multiple dependencies

• Use @Test(dependsOnMethods = {"login", "search"}) to run a method only if both dependencies succeed.
• If any specified dependency is skipped/failed, the dependent method is skipped.

Advantage emphasized

• Avoid running tests that are guaranteed to fail due to earlier failures.
• Saves time/effort, especially when there are many dependent tests.

Key attribute mentioned

• dependsOnMethods is a parameter/attribute of the @Test annotation only.

---

2) TestNG Grouping of Tests (executed via XML)

Purpose of grouping

• In real projects you might have many test methods and you don’t want to run everything every time.
• Group test methods into categories based on testing type and execution needs.

Typical groups discussed

• Sanity: quick/basic functionality checks (e.g., login/signup)
  • If sanity fails, deeper checks shouldn’t proceed.
• Regression: rerun tests to verify fixes after developers provide a build.
• Functional (combined category): methods that belong to both sanity and regression (created as a combined group for execution).

Where grouping is defined

• In the test code using the groups attribute inside @Test.
• Selection is controlled in a TestNG XML file.

Methodology / implementation steps shown (end-to-end)

1. Create multiple test classes, each containing several @Test methods. Example classes: LoginTest, SignUpTest, PaymentTest

2. Assign group tags to each test method using @Test(groups = "..."):

   • login by email/facebook/twitter → groups = "sanity"
   • sign up by email/facebook/twitter → groups = "regression"
   • payment in rupees/dollars → groups = {"sanity","regression"} (a method can belong to multiple groups)

3. Create an XML suite (manually or via Eclipse auto-generation):

   • Base XML structure includes:
     • <!suite name="...">
     • <test name="...">
     • <classes>
       • <class name="fully.qualified.ClassName"/>

4. Filter which groups run in XML:

   • Add a <groups> section (placed before the <classes> tag in the suite/test setup).
   • Use:
     • <run> with <include> to select only certain groups
     • <run> with <exclude> to skip certain groups

XML filtering behavior demonstrated

• Run only one group

  • Include sanity → executes only sanity-tagged tests across all classes.

• Run one group but exclude another

  • Include sanity and exclude regression
  • Runs sanity tests that are NOT also regression (excludes tests tagged with both).

• Run “regression but not sanity”

  • Include regression and exclude sanity
  • Keeps only regression-only tests (excluding overlap).

• Run only tests that belong to BOTH groups

  • Including both groups in XML alone doesn’t enforce a logical “AND” (it behaves like a union).
  • Solution: create a new combined group name (e.g., functional) and tag the overlap methods with it:
    • In code: groups = {"sanity","regression","functional"}
    • In XML: include only functional

Key attribute mentioned

• groups is an attribute of the @Test annotation.
• XML include/exclude tags control which group-labeled methods execute.

---

Speakers / sources featured

• No specific person’s name is provided in the subtitles (speaker is referenced generically as the instructor).