Video summary

Session 56: Selenium with Java | Hybrid Framework | Jenkins CI Setup | (Final Session)

Main summary

Key takeaways

Technology

Main technical concepts: CI/CD + DevOps workflow

  • Jenkins as a Continuous Integration (CI) tool

    • When code is pushed to GitHub, Jenkins automatically:
      • pulls the repository
      • builds/packages the application
      • runs automation tests

  • Continuous Integration definition

    • Developers continuously commit/push code throughout the day.
    • Nightly builds trigger a cycle of build + testing, producing multiple builds until testing ends.

  • Continuous Delivery/Deployment (CD)

    • After tests complete successfully, the software build is released/deployed to customer environments continuously.

  • Ownership model (real DevOps setups)

    • Jenkins is typically managed/owned by the DevOps/Release engineering team.
    • Engineers usually get access (e.g., a URL) rather than installing Jenkins themselves.

Jenkins architecture & features mentioned

  • Admin + multiple users

    • Jenkins has an administrator/controller who creates user accounts.
    • Jenkins is web-based, so users access it via a URL.

  • Pipeline concept

    • Pipelines are described as staged steps such as:
      • coding → build creation/packaging → automated execution (testing) → deploy
    • Pipelines can be scheduled/triggered automatically using Jenkins scheduling.

  • Execution environment

    • Jenkins typically runs tests in headless mode by default in DevOps/real environments (no UI focus).
    • A “WAR-file learning mode” execution may show UI/headed behavior for demonstration.

Test automation strategy & how Jenkins reduces time

  • Where tests run

    • Sanity/regression/functional tests are largely executed inside Jenkins during build creation.
    • Recommended flow:
      • Run tests locally first
      • Then commit/push changes to GitHub

  • Test case lifecycle

    • For new features/bug fixes:
      1. Add/update test cases
      2. Commit/push to GitHub
      3. Jenkins executes them automatically on the next build

  • Debug loop (if Jenkins fails)

    • Check console output
    • Fix code/test cases
    • commit/push
    • Rerun Jenkins

Jenkins installation guide (WAR file approach)

Download & install

  • Jenkins is installed using a WAR file (generic Java package) for learning.
  • Release tracks mentioned:
    • LTS (Long Term Support) is preferred
    • Weekly releases are not preferred

Running Jenkins locally

  • Start Jenkins with:
    • java -jar jenkins.war
  • First startup behavior:
    • Jenkins generates an initial admin unlock password (copy it)
    • Jenkins runs on localhost:8080
  • Unlock process:
    • Open the browser to localhost:8080
    • Paste the admin password
  • Plugins:
    • Suggested plugins are installed by default (additional plugins can be added later)
  • Admin setup:
    • Admin username/password set during setup (described as admin/admin)

Start/stop behavior

  • With WAR-file learning installation:
    • Stop Jenkins by stopping the WAR process (i.e., stop/close the terminal-run process)
  • In real environments:
    • Jenkins is usually installed as a service/executable and runs continuously

Post-install Jenkins configuration (one-time setup)

Plugins required

  • Git plugin / GitHub-related plugins (mentioned as installed in their demo)
  • Maven plugin
    • May require manual installation from Available plugins if not present
  • Manage plugins via:
    • Jenkins → Manage Jenkins → Plugins

Tool paths (mandatory configuration)

Under Manage Jenkins → Tools, configure paths for:

  • JDK (Java) installation
  • Git executable
  • Maven (Maven home path)

These paths must match what exists on the machine where Jenkins runs.

Creating and running a Jenkins job (Maven + GitHub)

Job creation

  • Create a Maven project (preferred for real projects).
  • In Source Code Management:
    • Select Git
    • Provide the GitHub repository URL

Build step

  • In Build → Invoke top-level Maven targets:
    • Use Goals/Options such as test
    • Jenkins uses pom.xml automatically as the entry point

Execution

  • Click Build Now
  • Jenkins will:
    • pull code from GitHub
    • run the Maven test suite
    • display:
      • progress bar + console output
      • success/failure indicators on the dashboard

Running local projects vs remote Jenkins (important constraint)

  • If Jenkins runs on a different machine (e.g., a DevOps server):

    • You cannot run your Eclipse-local project paths directly in that remote Jenkins.
    • Reason: JDK/Maven/Git paths are configured for the remote machine, not your local setup.

  • Recommended real workflow:

    • Push project to GitHub
    • Configure Jenkins to pull from GitHub
    • Run via Jenkins

Alternative: running local project in local Jenkins

  • If Jenkins runs on the same local machine, you can point Jenkins to local project files and run by:
    • specifying a pom.xml path, or
    • using run.bat via a Freestyle project with Windows batch steps
  • Freestyle is described as mainly for demo; Maven + GitHub is preferred for real workflows.

Hybrid Selenium framework notes (session content added)

Framework components/automation

Mentions a hybrid Selenium WebDriver framework using:

  • Page Object classes
  • Test cases
  • Test base / utilities
  • Resources
  • Reports/logs/screenshots

It uses Maven + TestNG-style execution via pom.xml (test execution described via mvn test).

Grid/Docker-related commands (newly covered here)

Provides commands (in text files) to run:

  • Standalone Grid
  • Grid using Docker Compose
  • Stop containers

Remote-grid setup reminders:

  • Ensure configuration targets remote
  • Use a global URL, not localhost
  • Choose the correct XML suite file for the target environment:
    • Standalone vs Docker grid

XML-based test grouping

  • Multiple XML files are used to control what runs:
    • grouping suites across different XMLs
    • selecting the desired XML in pom.xml before remote execution

End-to-end test example constraints

  • End-to-end flow mentioned:
    • account registration → login → search → add to cart → checkout → capture total price/validation
  • Notes:
    • payment/email is limited by the demo application
    • payment/email options may not work

Project sharing

  • The final project is shared via Google Drive (not pushed to GitHub in their described final step).
  • The user can download and import it into Eclipse; GitHub contains the earlier basic code.

Main speakers/sources (from subtitles)

  • Primary speaker/instructor
    • Main voice throughout the session
    • No named guest speakers

Original video