Session 45 - Selenium with Java | TestNG | DataProviders | Parallel Testing

Main ideas / lessons from the session

1) Parameterization in TestNG (what it means)

• Parameterization = passing input parameters into TestNG tests at runtime.
• This session covered two main ways of parameterization:
  1. Using a @DataProvider (for data-driven testing; repeats the same test with different data sets, typically without explicit loops).
  2. Using TestNG XML parameters (especially for cross-browser testing and parallel execution).

---

2) Data Provider (@DataProvider) — for data-driven testing

Key concept

A data provider method:

• creates/prepares test data
• returns it to one or more test methods
• does not execute the application/testing itself

The test method runs automatically once for each data set returned.

How it differs from Excel + loops

• Earlier (Excel-driven) approach:
  • requires looping to iterate rows/cells
  • reads one row at a time and executes tests per iteration
• With @DataProvider:
  • TestNG repeats the test method without explicit looping inside the test
  • TestNG manages repetition/indexing internally

Example structure (logic-level)

• Test class annotations
  • @BeforeClass / setup: launch browser (runs once)
  • @Test / login test: performs login validation (runs multiple times when connected to @DataProvider)
  • @AfterClass / teardown: close browser (runs once after all repetitions)

Method responsibilities

• Setup method
  • initializes WebDriver (e.g., ChromeDriver)
  • prepares prerequisites (open browser, open application URL)
• Test method (e.g., testLogin)
  • accepts parameters like email and password
  • performs login
  • validates outcome using assertions
• Data provider method (e.g., loginData)
  • returns a 2D array of test inputs (email/password combinations)
  • supplies these data sets to the test method

Data provider return type requirement (as taught)

• Data provider returns a 2D array:
  • often Object[][] (to support mixed data types)
  • can also be typed with String[][] depending on content, but the session emphasized Object[][].

Connecting a test method to a data provider

• In the @DataProvider, you must give a name (e.g., "DP").
• In the @Test, reference it using:
  • dataProvider = "<same name>"

Automatic repetition behavior (important)

• If the data provider returns N inputs, then:
  • the connected test method runs N times
• No explicit indexing / for loop is needed inside the test method.

---

3) Data Provider advanced feature: selecting specific indices

Purpose

Control which rows (data sets) from the provider are used by the test.

Instruction format (as taught)

In @DataProvider, use:

• indices = { ... }

Notes:

• array indexing starts at 0
• you can specify:
  • a subset (e.g., first two: indices = {0, 1})
  • first and last: indices = {0, 4}
  • any combination (e.g., indices = {0, 3, 4})

Effect

• The test method executes only for the selected indices’ data sets.

---

4) Organization best practice (framework mindset)

• In real frameworks, data provider methods are often moved into a separate class dedicated to data providers.
• Benefits:
  • reuse across multiple test classes
• Naming constraint emphasized:
  • the name of each data provider must be unique within the shared provider context.

---

5) XML parameterization in TestNG (for cross-browser + parallel testing)

Where XML fits

• TestNG XML controls how tests run, typically as a suite.
• XML can pass parameters to tests/fixtures.

Step-by-step methodology (as taught) for browser parameterization

1. Create a TestNG test class with browser-dependent setup (e.g., @BeforeClass setup()).
2. Add parameters to the XML:
   • use a <parameter> tag
   • example concept: parameter name "browser" with values like "Chrome", "Edge", "Firefox".
3. In Java, read the parameter in the setup method:
   • add @Parameters({"browser"})
   • accept an argument like String browserName
4. In setup, choose browser at runtime:
   • use conditional logic (the session showed a switch on browserName)
   • handle:
     • Chrome
     • Edge
     • Firefox
     • invalid values: print an error and return to exit setup so later code doesn’t run without a driver

Critical requirement

• Running the test without XML fails because the required parameter isn’t provided.

---

6) Cross-browser execution strategies using XML

A) Serial execution across browsers (sequential)

• Create multiple <test> entries in the XML suite.
• Each <test> entry:
  • uses the same test class
  • sets a different browser parameter value (Chrome, Edge, Firefox)
• Tests run one after another (serially).
• Requirement:
  • test names in XML should differ (e.g., “Chrome Test”, “Edge Test”, “Firefox Test”).

B) Parallel execution across browsers (concurrent)

1. In the XML suite, set (as taught):
   • parallel="tests"
2. Also set thread-count:
   • default may be 1, which causes serialization
   • increase thread count to enable true parallel execution
3. Guidance:
   • recommended thread count range: 2 to 5
   • too many threads can reduce performance or increase instability

Advantage of parallel execution (as taught)

• Reduces total runtime when there are many test cases.
• Gains become clearer as test volume increases.

---

7) Passing multiple parameters from XML (example: browser + URL)

Method taught

• Add multiple <parameter> entries in XML (e.g., "browser" and "url").
• Receive them in setup using:
  • @Parameters({"browser", "url"})
• Use both values inside setup:
  • select browser using browser
  • navigate using url

Note from the session

• The presenter noted that URL may be the same across browsers in many scenarios, but the pattern was shown for completeness.

---

Speakers / sources featured

• Speaker: Not explicitly named in the subtitles (an unnamed instructor/presenter).