Session 43 - Selenium with Java | TestNG Annotations | Types Of Assertions

Main Ideas and Lessons

• The session continues TestNG basics by introducing TestNG annotations (especially lifecycle annotations) and then explains assertions (validations) in TestNG.
• Key takeaway: Annotations control execution order. Only methods annotated with @Test are treated as “test methods” and appear as passed/failed in reports. Other annotated helper methods may run, but they won’t show as test results unless they are @Test.
• After understanding annotation scopes, the session explains why assertions are preferred over plain if/else checks for correct pass/fail reporting.
• It distinguishes between hard assertions and soft assertions, including their behavioral differences and when to use them.

---

Methodical Concepts: TestNG Annotation Hierarchy & Usage

1) Core @Test Annotation (Main Tests)

• A method is treated as a test method only if it is annotated with @Test.
• Optional: priority can be specified; TestNG uses it to decide execution order among test methods.

Validation rule

• Put actual validations inside @Test methods.
• Helper methods (e.g., login/logout) should not contain validations if you don’t want them to appear in reports as test results.

---

2) @BeforeMethod / @AfterMethod (Runs Before/After Each @Test)

Use case demonstrated

• Repeated steps needed around each test method, such as:
  • Entry (e.g., login) before each test
  • Exit (e.g., logout) after each test

Example scenario

• Two tests: search and advancedSearch
• Login/logout act as prerequisites/teardown and are repeated around each test.

Execution behavior

• If there are N test methods in the class:
  • @BeforeMethod runs N times
  • @AfterMethod runs N times

Implementation idea from the session

• Mark the main tests with @Test, e.g.:
  • search (priority example)
  • advancedSearch (priority example)
• Mark prerequisite/teardown once in code but let TestNG repeat it:
  • @BeforeMethod for login()
  • @AfterMethod for logout()

---

3) @BeforeClass / @AfterClass (Runs Once Per Class)

Use case demonstrated

• Shared setup/teardown used by both main tests:
  • login only once before any test methods in the class
  • logout only once after all test methods in the class

Execution behavior

• For a given class:
  • @BeforeClass runs once
  • @AfterClass runs once
• This happens regardless of the number of @Test methods in that class.

Rule highlighted

• It’s not mandatory to use both:
  • You may use only @BeforeClass if you don’t need explicit teardown.
  • Use @AfterClass only if you must perform actions after all tests in the class.

---

4) @BeforeTest / @AfterTest (Runs Once Per TestNG <test> in XML)

Important conceptual point (from XML hierarchy)

• In XML, a <test> tag groups one or more classes.
• Therefore:
  • @BeforeTest / @AfterTest operate at the XML <test> level, not the Java class level.

Execution behavior described

• If XML has:
  • one <test> containing classes C1, C2:
    • @BeforeTest runs once before those classes execute
    • @AfterTest runs once after they finish
  • two <test> entries (Test1 and Test2), each with different classes:
    • @BeforeTest runs once per XML test
    • @AfterTest runs once per XML test

Method placement

• @BeforeTest / @AfterTest methods can be placed in any of the involved classes (e.g., C1 or C2).
• TestNG decides timing based on annotation + XML grouping.

---

5) @BeforeSuite / @AfterSuite (Runs Once Per Suite in XML)

Use case

• Suite-level actions before/after running all tests contained in a suite.

Execution behavior

• @BeforeSuite runs once at the start of the suite
• @AfterSuite runs once at the end of the suite

Session note

• Teams often use multiple separate suites (multiple XML files), so before/after suite usage is rarer in practice.

---

6) Final Hierarchy (Execution Level Concept)

The session summarizes the hierarchy as:

• Suite level: @BeforeSuite / @AfterSuite
• Test level: @BeforeTest / @AfterTest
• Class level: @BeforeClass / @AfterClass
• Method level: @BeforeMethod / @AfterMethod
• Test method level: methods annotated with @Test

Key reporting principle

• Reports primarily reflect the status of @Test methods (not helper methods), even though helper methods run during execution.

---

Assertions: Validations and Reporting Correctness

Why assertions are needed

• Earlier approach used if/else:
  • compare expectedTitle vs actualTitle
  • print “test passed/failed”
• Problem:
  • Even if your if condition fails, TestNG may still mark the @Test method as PASS unless you explicitly fail it using TestNG assertions.

Assertions ensure

• pass/fail status is correctly reflected in TestNG reports.

---

Hard Assertions vs Soft Assertions

A) Hard Assertions (Common Case)

• Implemented using TestNG’s Assert class.
• These assertions are static calls (no object needed), for example:
  • Assert.assertEquals(...)
  • Assert.assertNotEquals(...)
  • Assert.assertTrue(...)
  • Assert.assertFalse(...)
  • Assert.fail()

Core behavior

• If a hard assertion fails:
  • the test method effectively stops further execution
  • remaining lines/prints after the failing assertion do not run

Common hard assertion types described

• Equality / inequality:
  • assertEquals(expected, actual)
  • assertNotEquals(expected, actual)
• Boolean checks:
  • assertTrue(conditionOrExpected, message?)
  • assertFalse(condition)
• Explicit failure:
  • fail() to force failure immediately

---

B) Soft Assertions (Continue After Failures)

• Implemented via a SoftAssert object (not static).
• Example pattern:
  • SoftAssert softAssert = new SoftAssert();
  • use soft assertion methods like:
    • softAssert.assertEquals(...)
    • softAssert.assertTrue(...)
    • etc.
  • IMPORTANT: call at the end:
    • softAssert.assertAll();

Core behavior

• If a soft assertion fails:
  • execution continues for remaining steps
• But correct failure reporting happens only when you call:
  • assertAll() at the end

Important rule emphasized

• Without assertAll(), soft assertions may not properly fail the test in results.

---

Speakers / Sources Featured

• No explicit individual speakers are identified in the subtitles.
• Source: The content appears to be from a YouTube/TestNG tutorial video titled:
  • “Session 43 - Selenium with Java | TestNG Annotations | Types Of Assertions”