DEV Community: Serhat Ozdursun

Shipping AI into Your CI: Coverage-Aware Reviews with Danger + OpenAI (and SonarCloud)

Serhat Ozdursun — Wed, 03 Sep 2025 09:40:13 +0000

I believe the best way to learn is by doing. But in a busy job, you don’t always get to try new tech on company time. That can’t be an excuse—our field moves fast, and AI is one of the biggest shifts right now.

My day-to-day didn’t include AI work, so I turned to my personal website repo as a safe sandbox: serhatozdursun/resume. It’s the perfect “lab mouse.” I wanted to explore AI-assisted quality gates: the things we already rely on in QA—static analysis, unit tests, code reviews—augmented with an assistant that understands the diff and helps us ship better.

This post walks through the pipeline I built: SonarCloud + Jest coverage + Danger + OpenAI, wired together with Secrets so I can tune behavior without touching YAML.

What you get

✅ SonarCloud for static analysis + PR decoration + coverage dashboards.
✅ A coverage gate on changed code (e.g., 80% on lines you touched).
✅ AI unit test suggestions generated directly from the diff (copy-paste-ready Jest/TS).
✅ AI code review that posts a concise diff snippet (old → new) with an explanation.
(No fragile line numbers; we still add inline notes when mapping is reliable.)
✅ Secret-driven knobs so you can change thresholds/toggles from CI Secrets—no PRs to change policy.

Architecture (bird’s eye)

Tests & coverage: Jest runs and writes coverage/lcov.info.
SonarCloud: runs as usual for code smells and coverage on new code.
Danger + OpenAI (same job):

Reads the PR diff.
Computes new-lines coverage per changed file from LCOV.
If below MIN_FILE_COVERAGE, fails the PR and posts AI test ideas.
Regardless of coverage, asks OpenAI to:
- propose copy-pasteable Jest tests, and
- do a short code review with actionable notes and a tiny diff snippet.
All behavior is toggled by environment variables you define as secrets. ## One workflow for both PRs and main (AI runs only for PRs)

I keep one file so everything lives in one place. The workflow triggers on PRs and on pushes to main, but the AI step is gated so it only runs on PRs.

name: Code Quality (Tests + SonarCloud + AI Review)

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
  push:
    branches: [main]

permissions:
  contents: read
  pull-requests: write
  statuses: write

# Optional hardening: avoid duplicate runs while a PR is updated
concurrency:
  group: qg-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test-and-analyze:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with: { fetch-depth: 0 }

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'yarn'

      - name: Install deps
        run: yarn install --frozen-lockfile

      - name: Run unit tests (with coverage)
        run: yarn test --coverage

      - name: SonarCloud Scan
        uses: SonarSource/sonarcloud-github-action@v5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

      - name: Upload coverage report (PRs only)
        if: ${{ github.event_name == 'pull_request' }}
        uses: actions/upload-artifact@v4
        with:
          name: coverage-html
          path: coverage/lcov-report/

      - name: Install Danger deps
        if: ${{ github.event_name == 'pull_request' }}
        run: yarn add -D danger lcov-parse openai

      - name: Run AI coverage-aware review
        if: ${{ github.event_name == 'pull_request' }}
        env:
          # Required
          DANGER_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

          # Optional knobs (set via Secrets to avoid editing YAML)
          # MIN_FILE_COVERAGE:            ${{ secrets.MIN_FILE_COVERAGE }}   # default 80
          # MAX_FILES_TO_ANALYZE:         ${{ secrets.MAX_FILES_TO_ANALYZE }}# default 3
          # OPENAI_MODEL:                 ${{ secrets.OPENAI_MODEL }}        # default gpt-4o-mini
          # DANGER_ALWAYS_NEW_COMMENT:    ${{ secrets.DANGER_ALWAYS_NEW_COMMENT }} # default off
          # AI_REVIEW_ENABLED:            ${{ secrets.AI_REVIEW_ENABLED }}    # default 1
          # AI_REVIEW_INLINE:             ${{ secrets.AI_REVIEW_INLINE }}     # default 1
          # AI_REVIEW_BLOCK_ON_FINDINGS:  ${{ secrets.AI_REVIEW_BLOCK_ON_FINDINGS }} # default off
          # AI_REVIEW_MAX_CHARS:          ${{ secrets.AI_REVIEW_MAX_CHARS }}  # default 100000
          # AI_REVIEW_MAX_FINDINGS:       ${{ secrets.AI_REVIEW_MAX_FINDINGS }} # default 8
        run: npx danger ci --dangerfile dangerfile.ts

Why this pattern?

Single file keeps maintenance low.
AI job runs only on PRs (if:), so merging to main doesn’t re-comment PRs.
You still get tests + Sonar on pushes to main.

The `dangerfile.ts` — what it actually does

1) Coverage gate on changed code

We parse coverage/lcov.info using lcov-parse.
We fetch the PR diff and compute coverage on new/modified instrumented lines.
If that effective coverage is below MIN_FILE_COVERAGE (default 80), we:
- fail the PR,
- post a table showing per-file new-lines coverage and whole-file coverage, and
- ask the AI for test ideas (see next).

2) AI unit test suggestions (copy-paste ready)

Prompt instructs the model: “You’re a senior TS/React dev. Output one Markdown code block: a runnable Jest TS test file. Keep it minimal but cover branches and edge cases implied by the diff. Use a file name like src/tests/.auto.test.ts.”

You can always generate suggestions, or only when coverage dips below the threshold—toggle with Secrets.

3) AI code review (snippet-first + optional inline)

We enumerate added lines per file and ask the AI to return JSON findings:

{ 
  "file": "src/pages/index.tsx", 
  "index": 0, 
  "severity": "warn", 
  "title": "...", 
  "body": "..."
}

For each finding, we create a concise diff snippet centered around that added line and post it as a file-scoped comment, with explanation and suggested fix.
(This avoids wrong line numbers; the snippet shows the exact old → new change.)
If mapping is available, we also add an inline note (secondary signal).
If you set AI_REVIEW_BLOCK_ON_FINDINGS="1", any fail severity will fail the PR.

“Knobs” behind Secrets (and not just on GitHub)

The behavior is entirely env-driven, so you can change policy without opening PRs:

Required
- DANGER_GITHUB_API_TOKEN (or GITHUB_TOKEN) — lets Danger comment & set statuses.
- OPENAI_API_KEY — used for test ideas + AI code review.
Optional (defaults already in dangerfile.ts)
- MIN_FILE_COVERAGE → default 80
- MAX_FILES_TO_ANALYZE → 3
- OPENAI_MODEL → gpt-4o-mini
- DANGER_ALWAYS_NEW_COMMENT → off (set "1" to force fresh comment per push)
- AI_REVIEW_ENABLED → "1"
- AI_REVIEW_INLINE → "1"
- AI_REVIEW_BLOCK_ON_FINDINGS → off (set "1" to enforce blocking)
- AI_REVIEW_MAX_CHARS → 100000
- AI_REVIEW_MAX_FINDINGS → 8

Not using GitHub Actions? The exact same env names work in other CI/CDs—store them in that platform’s secret manager:

AWS CodeBuild/CodePipeline → AWS Secrets Manager / SSM Parameter Store

Bitbucket Pipelines → Repository Variables (secured)

Azure DevOps → Library Variable Groups and/or Azure Key Vault

GitLab CI → CI/CD Variables (masked/protected)

CircleCI → Project Environment Variables or Contexts

The “secret knobs” pattern is portable; only the secret store changes.

Optional hardening

Concurrency (already in the YAML): prevents duplicate runs while developers push more commits.
Fail early if LCOV missing (add right before Danger step if you prefer a clear error):

- name: Assert LCOV present
  if: ${{ github.event_name == 'pull_request' }}
  run: |
    test -f coverage/lcov.info || (echo "coverage/lcov.info not found" && exit 1)

Pin tool versions (optional): npx -y danger@<pinned> ci --dangerfile dangerfile.ts

Rollout plan

Start with suggestions only (no blocking).
Set MIN_FILE_COVERAGE="80"; raise to 85–90 if the team is comfortable.
Keep snippet-first review; enable inline (AI_REVIEW_INLINE="1") for extra hints.
Flip AI_REVIEW_BLOCK_ON_FINDINGS="1" when you’re ready for strict enforcement.

Final thoughts

This setup lets you practice AI-augmented code quality in a real repo without disrupting anything. SonarCloud continues to do the heavy lifting for static analysis and coverage dashboards; Danger + OpenAI add targeted, actionable feedback on the code you changed today—and can enforce gates when you’re ready.

Add the workflow.
Drop in the dangerfile.ts.
Set your Secrets.
Open a PR and watch the reviewer go to work.

🧪 GitHub Actions Matrix Strategy - Part 2: Email Notifications with Artifact Links via EmailJS

Serhat Ozdursun — Mon, 14 Apr 2025 13:50:51 +0000

In Part 1 of this series, we explored how to use GitHub Actions matrix strategy to run UI automation tests across multiple browsers like Chrome and Firefox in parallel. It was fast, flexible, and scalable.

But once your matrix jobs run… how do you get notified when something breaks — and more importantly, which browser failed?

In this article, we’ll take it one step further by sending smart email notifications per browser, including:

📬 Pass/fail status
🧪 Commit SHA
📎 Direct link to the HTML test report (via GitHub Artifacts)
✅ Fully integrated with EmailJS dynamic templates

Let’s dive in!

📬 Why Use EmailJS?

💡 What is EmailJS?

EmailJS allows developers to send emails directly from frontend apps or serverless environments — without needing to set up their own email server or SMTP credentials.

You define templates with variables (like {{result}}, {{browser}}), and send data via a simple REST API. It’s perfect for tools like GitHub Actions or CI/CD pipelines.

🛠 Other Tools You Could Use

Tool	Highlights	Notes
SendGrid	Full-featured transactional email API	Setup is more involved
Mailgun	Developer-focused with detailed tracking	Ideal for backend use
SMTP2GO	Traditional SMTP service	Works well with SMTP clients
Postmark	Reliable transactional delivery and analytics	Paid plan, high deliverability
EmailJS	No server needed, simple setup, free tier	Best for client-side & CI/CD

✅ Why I Chose EmailJS

No backend needed – works directly from GitHub Actions
Easy template setup – fully customizable UI
Free plan – generous for small projects or teams
Quick integration – REST API is simple and secure
Works well with matrix workflows – send dynamic info per job

📄 Dynamic Email Templates in EmailJS

Instead of hardcoding email content in your GitHub workflow, you can define a template in EmailJS like this:

Now we just pass values to these placeholders from GitHub Actions using template_params.

⚙️ Updated GitHub Actions Workflow (with EmailJS Integration)

Here's the key part of your workflow that:

Sends an email for each matrix browser job
Uses dynamic data
Links directly to the uploaded HTML test report

✅ Success Email Step

- name: Send Success Email for ${{ matrix.browser }}
  if: success()
  env:
    EMAILJS_SERVICE_ID: ${{ secrets.EMAILJS_SERVICE_ID }}
    EMAILJS_TEMPLATE_ID: ${{ secrets.EMAILJS_TEMPLATE_ID }}
    EMAILJS_USER_ID: ${{ secrets.EMAILJS_USER_ID }}
  run: |
    ARTIFACTS_LINK="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}"

    cat <<EOF > email-payload-success.json
    {
      "service_id": "${EMAILJS_SERVICE_ID}",
      "template_id": "${EMAILJS_TEMPLATE_ID}",
      "user_id": "${EMAILJS_USER_ID}",
      "template_params": {
        "title": "✅ UI Test Passed",
        "result": "passed successfully",
        "browser": "${{ matrix.browser }}",
        "commit": "${{ github.sha }}",
        "artifacts_link": "${ARTIFACTS_LINK}"
      }
    }
EOF

    curl -X POST https://api.emailjs.com/api/v1.0/email/send \
      -H 'origin: http://localhost' \
      -H 'Content-Type: application/json' \
      -d @email-payload-success.json

❌ Failure Email Step

- name: Send Failure Email for ${{ matrix.browser }}
  if: failure()
  env:
    EMAILJS_SERVICE_ID: ${{ secrets.EMAILJS_SERVICE_ID }}
    EMAILJS_TEMPLATE_ID: ${{ secrets.EMAILJS_TEMPLATE_ID }}
    EMAILJS_USER_ID: ${{ secrets.EMAILJS_USER_ID }}
  run: |
    ARTIFACTS_LINK="https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}"

    cat <<EOF > email-payload-failure.json
    {
      "service_id": "${EMAILJS_SERVICE_ID}",
      "template_id": "${EMAILJS_TEMPLATE_ID}",
      "user_id": "${EMAILJS_USER_ID}",
      "template_params": {
        "title": "❌ UI Test Failed",
        "result": "failed",
        "browser": "${{ matrix.browser }}",
        "commit": "${{ github.sha }}",
        "artifacts_link": "${ARTIFACTS_LINK}"
      }
    }
EOF

    curl -X POST https://api.emailjs.com/api/v1.0/email/send \
      -H 'origin: http://localhost' \
      -H 'Content-Type: application/json' \
      -d @email-payload-failure.json

📬 Real Email Example

Here's what the email looks like when a test passes for the Firefox browser:

This is powered by an EmailJS template using variables like {{browser}}, {{commit}}, and {{artifacts_link}}. Everything is injected dynamically per matrix job.

You can even include emojis, links, or styling directly in the EmailJS editor!

🎁 Final Thoughts

This setup gives you full visibility over your GitHub test matrix:

Who broke what browser
Direct link to test artifacts
Stylish notifications in your inbox

No backend. No SMTP. Just clean, dynamic emails — in under 10 minutes.

🧩 What’s Next?

In the next article (Part 3), I’ll show you how to:

Combine multi-browser reports into one HTML dashboard
Attach that in a Slack or Teams notification
Make your matrix strategy 100% team-ready

💬 Questions or improvements?
💼 Connect with me on LinkedIn
🌐 More at serhatozdursun.com

🧪 GitHub Actions Matrix Strategy - Part 2: Send Email Notifications with Test Artifacts

Serhat Ozdursun — Mon, 14 Apr 2025 12:10:21 +0000

But once your matrix jobs run… how do you get notified when something breaks — and more importantly, which browser failed?

In this article, we’ll take it one step further by sending smart email notifications per browser, including:

📬 Pass/fail status
🧪 Commit SHA
📎 Direct link to the HTML test report (via GitHub Artifacts)
✅ Fully integrated with EmailJS dynamic templates

Let’s dive in!

📬 Why Use EmailJS?

💡 What is EmailJS?

EmailJS allows developers to send emails directly from frontend apps or serverless environments — without needing to set up their own email server or SMTP credentials.

You define templates with variables (like {{result}}, {{browser}}), and send data via a simple REST API. It’s perfect for tools like GitHub Actions or CI/CD pipelines.

🛠 Other Tools You Could Use

Tool	Highlights	Notes
SendGrid	Full-featured transactional email API	Setup is more involved
Mailgun	Developer-focused with detailed tracking	Ideal for backend use
SMTP2GO	Traditional SMTP service	Works well with SMTP clients
Postmark	Reliable transactional delivery and analytics	Paid plan, high deliverability
EmailJS	No server needed, simple setup, free tier	Best for client-side & CI/CD

✅ Why I Chose EmailJS

No backend needed – works directly from GitHub Actions
Easy template setup – fully customizable UI
Free plan – generous for small projects or teams
Quick integration – REST API is simple and secure
Works well with matrix workflows – send dynamic info per job

📄 Dynamic Email Templates in EmailJS

Instead of hardcoding email content in your GitHub workflow, you can define a template in EmailJS like this:

Subject:



{{title}} - {{browser}} {{time}}

What is GitHub Actions Matrix Strategy?

Serhat Ozdursun — Wed, 09 Apr 2025 16:21:42 +0000

The GitHub Actions matrix strategy is a powerful feature that allows you to run the same job across multiple combinations of variables—like environments, operating systems, or software versions—without duplicating code. It's ideal for scenarios such as:

Testing across different browser environments
Running code against multiple versions of a language
Deploying across multiple platforms (e.g., Android and iOS)

By using a strategy.matrix section in your workflow, you can define all the variations you want to test or execute. GitHub will then automatically create a job for each combination. This not only helps keep workflows clean and scalable, but also provides a clear view of which combinations succeed or fail.

For example:

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node: [16, 18]

This configuration will run four jobs in parallel:

Ubuntu + Node 16
Ubuntu + Node 18
Windows + Node 16
Windows + Node 18

Learn more in the official GitHub Docs

Cross-Browser UI Testing with GitHub Actions Matrix Strategy

When building UI automation workflows, one of the most common challenges is ensuring consistent functionality across different browsers. Initially, I handled this by creating separate GitHub Actions YAML files for each browser:

ui_chrome_pytest.yml
ui_firefox_pytest.yml

Each file had almost identical steps, with only minor differences:

🔍 Key Differences in the Old Files

ui_chrome_pytest.yml manually installs Google Chrome and ChromeDriver.

ui_firefox_pytest.yml uses the browser-actions/setup-firefox action for Firefox and GeckoDriver.

The pytest command uses --browser chrome in one and --browser firefox in the other.

Both upload the same artifacts, but the file names are not browser-specific (they would overwrite each other if run together).

This setup worked, but had several downsides:

❌ Duplication of logic: Every change had to be applied in multiple files.
❌ Error-prone: It’s easy to forget updating one file.
❌ Scalability issues: Adding more browsers or platforms meant creating even more nearly-identical files.

The Solution: Matrix Strategy

So, to eliminate the duplication and better manage different browser setups, I leveraged the GitHub Actions matrix strategy. This approach allows each browser to be tested in parallel, using a single, unified workflow file.

To solve this, I created a new GitHub Actions workflow using a matrix strategy that dynamically switches between browsers:

ui_cross_browser_test.yml

name: UI Automation Tests

on:
  pull_request:
    branches:
      - main

jobs:
  build_and_test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        browser: [chrome, firefox] # Matrix used to define browsers to test

    steps:
      - name: Checkout resume repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'

      - name: Install dependencies and build
        run: |
          yarn install
          yarn build

      - name: Start the application
        run: |
          yarn start &
        env:
          PORT: 3000

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      # Chrome-specific installation
      - name: Install Chrome and ChromeDriver
        if: matrix.browser == 'chrome'
        run: |
          sudo apt update
          sudo apt install -y wget gnupg
          wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
          sudo apt install -y ./google-chrome-stable_current_amd64.deb
          CHROMEDRIVER_VERSION=$(curl -sS https://chromedriver.storage.googleapis.com/LATEST_RELEASE)
          wget https://chromedriver.storage.googleapis.com/${CHROMEDRIVER_VERSION}/chromedriver_linux64.zip
          unzip chromedriver_linux64.zip
          sudo mv chromedriver /usr/local/bin/chromedriver
          sudo chmod +x /usr/local/bin/chromedriver

      # Firefox-specific setup using reusable action
      - name: Set up Firefox and GeckoDriver
        if: matrix.browser == 'firefox'
        uses: browser-actions/setup-firefox@latest

      - name: Clone the test repository
        run: |
          git clone https://github.com/serhatozdursun/serhatozdursun-ui-tests.git
        env:
          GITHUB_TOKEN: ${{ secrets.UI_TEST_TOKEN }}

      - name: Install Python dependencies
        working-directory: serhatozdursun-ui-tests
        run: |
          pip install -r requirements.txt

      # Matrix-aware pytest command
      - name: Run tests on ${{ matrix.browser }}
        working-directory: serhatozdursun-ui-tests
        id: run_tests
        run: |
          pytest --browser ${{ matrix.browser }} --base_url http://localhost:3000 --html=reports/html/report.html --junitxml=reports/report.xml

      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: html-report-${{ matrix.browser }}
          path: serhatozdursun-ui-tests/reports/html
          retention-days: 5
        continue-on-error: true

      - name: Upload XML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: xml-report-${{ matrix.browser }}
          path: serhatozdursun-ui-tests/reports/report.xml
          retention-days: 5
        continue-on-error: true

View the full workflow file

Before vs After

Approach	Pros	Cons
Separate files	Easy to isolate logic	Repetitive, hard to scale
Matrix strategy	Clean, DRY, scalable, browser-aware	Slightly more complex YAML logic

Final Thoughts

Using GitHub Actions' matrix strategy is a game-changer for cross-browser testing. If you're managing separate workflows per browser, consolidating them will make your CI setup much more efficient.

Stay sharp, test smart! 🚀🧪

Connect with me on GitHub: serhatozdursun.com

Java Checkstyle Tool: Enforce Coding Standards with Ease

Serhat Ozdursun — Tue, 25 Mar 2025 13:13:20 +0000

As software projects grow, maintaining code consistency becomes increasingly challenging—especially in teams. Java, being a verbose and widely-used language, is particularly prone to inconsistencies in formatting, naming, and structure. That’s where Checkstyle comes in.

What is Checkstyle?

Checkstyle is a static code analysis tool for Java that helps developers write code that adheres to a defined coding standard. It enforces style guidelines by checking source code against a configurable set of rules, making your codebase cleaner, more readable, and easier to maintain.

Whether you're working solo or in a team, using Checkstyle ensures uniformity and reduces time spent in code reviews discussing stylistic issues.

Key Features

Enforces coding standards (Google, Sun, or custom)
Detects common code smells
Integrates with Maven and Gradle
Supports IDE plugins (IntelliJ, Eclipse)
Highly customizable via XML config

Getting Started

For Maven Projects

Add the following plugin to your pom.xml:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-checkstyle-plugin</artifactId>
      <version>3.3.0</version>
      <configuration>
        <configLocation>google_checks.xml</configLocation>
        <encoding>UTF-8</encoding>
        <consoleOutput>true</consoleOutput>
        <failsOnError>true</failsOnError>
      </configuration>
      <executions>
        <execution>
          <phase>validate</phase>
          <goals>
            <goal>check</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

For Gradle Projects

Add the plugin to build.gradle:

plugins {
    id 'checkstyle'
}

checkstyle {
    toolVersion = '10.3.4'
    configFile = file('config/checkstyle/checkstyle.xml')
}

tasks.withType(Checkstyle) {
    reports {
        xml.required = false
        html.required = true
    }
}

Built-in or Custom Rules

Checkstyle supports built-in configurations:

google_checks.xml
sun_checks.xml

Or you can define custom rules. Below are some practical examples for test automation projects, like I did:

Prevent `Thread.sleep()`

<module name="Regexp">
  <property name="format" value="Thread\.sleep\(.*\)"/>
  <property name="illegalPattern" value="true"/>
  <property name="message" value="Do not use Thread.sleep(). Use an explicit wait instead."/>
</module>

Prevent `By.xpath(...)`

<module name="Regexp">
  <property name="format" value="By\.xpath\(.*\)"/>
  <property name="illegalPattern" value="true"/>
  <property name="message" value="Avoid using XPath locators. Use ID, class, or accessibility locators instead."/>
</module>

Prevent `System.out.println`

<module name="Regexp">
  <property name="format" value="System\.out\.println"/>
  <property name="illegalPattern" value="true"/>
  <property name="message" value="Use a logger instead of System.out.println."/>
</module>

Running Checkstyle

Maven:

mvn checkstyle:check

Gradle:

./gradlew checkstyleMain

Manual CLI:

java -jar checkstyle-10.3-all.jar -c /path/to/config.xml MyClass.java

GitHub Actions CI Integration

You can automate Checkstyle checks with GitHub Actions and prevent merging code that doesn't comply with your defined coding standards. This ensures every commit meets your team's style expectations before it's integrated into your main branch.

You can automate Checkstyle checks with GitHub Actions:

Create .github/workflows/checkstyle.yml:

name: Checkstyle

on: [push, pull_request]

jobs:
  checkstyle:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Build and Run Checkstyle
        run: mvn checkstyle:check

Use ./gradlew checkstyleMain instead if you're on Gradle.

IDE Support

IntelliJ IDEA: Use the CheckStyle-IDEA plugin
Eclipse: Use the Checkstyle Plugin via Eclipse Marketplace

Final Thoughts

Checkstyle is more than just a style enforcer—it's a tool that encourages code quality, team consistency, and professional discipline. Whether you're building a new application or maintaining legacy code, integrating Checkstyle is a low-effort, high-reward decision.

Start simple with Google or Sun checks, then evolve your configuration with custom rules that make sense for your team and project.

Streamlining Software Development with GitHub Actions: Automation, Testing, and Deployment

Serhat Ozdursun — Tue, 18 Mar 2025 12:19:32 +0000

GitHub Actions is a powerful CI/CD (Continuous Integration and Continuous Deployment) tool integrated directly into GitHub, allowing developers and QA engineers to automate, customize, and execute workflows within repositories. This tool simplifies the software development lifecycle by automating build, test, deployment, and other routine tasks directly from GitHub repositories.

Key Features of GitHub Actions:

Integrated CI/CD Workflows: Automate your development pipeline with ease.
Cross-platform Support: Execute workflows on Linux, macOS, and Windows.
Matrix Builds: Run multiple workflows in parallel with different configurations.
Extensive Marketplace: Utilize pre-built actions from a rich community-driven marketplace.
Real-time Feedback: Immediate visibility into the state of workflows and tests directly within GitHub pull requests and commits.
Secure Secrets Management: Store sensitive information securely with GitHub secrets.

Example: Static Code Analysis with CodeQL

Below is a practical example workflow for performing static code analysis on pull requests using CodeQL to detect vulnerabilities and quality issues in TypeScript and JavaScript code:

name: CodeQL Static Code Analysis

on:
  pull_request:
    branches: [main]

jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: read
      security-events: write

    strategy:
      matrix:
        language: ['typescript', 'javascript']

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        # Checks out your repository's code.

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v2
        with:
          languages: ${{ matrix.language }}
        # Initializes the CodeQL environment for specified languages.

      - name: Build code
        uses: actions/setup-node@v3
        with:
          node-version: '22'
        # Sets up Node.js environment.

      - run: |
          if [ -f package-lock.json ]; then
            npm install
          elif [ -f yarn.lock ]; then
            yarn install
          fi
        # Installs dependencies based on lock files.

      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v2
        # Runs the actual code analysis.

Using GitHub Actions for QA Automation

Quality Assurance engineers leverage GitHub Actions to run automated end-to-end (E2E) tests seamlessly within the development pipeline. Here’s a detailed example workflow for running UI Automation Tests on Chrome:

name: UI Automation Test for Chrome

on:
  pull_request:
    branches:
      - main

jobs:
  build_and_test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout resume repository
        uses: actions/checkout@v3
        # Fetches the latest code from the repository.

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '22'
        # Sets up the Node.js environment.

      - name: Install dependencies and build
        run: |
          yarn install
          yarn build
        # Installs necessary dependencies and builds the application.

      - name: Start the application
        run: |
          yarn start &
        env:
          PORT: 3000
        # Starts the application on port 3000.

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.12'
        # Sets up the Python environment for running test scripts.

      - name: Install Chrome
        run: |
          sudo apt update
          sudo apt install -y wget gnupg
          wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
          sudo apt install -y ./google-chrome-stable_current_amd64.deb
        # Installs Google Chrome for browser automation testing.

      - name: Install ChromeDriver
        run: |
          CHROMEDRIVER_VERSION=$(curl -sS https://chromedriver.storage.googleapis.com/LATEST_RELEASE)
          wget https://chromedriver.storage.googleapis.com/${CHROMEDRIVER_VERSION}/chromedriver_linux64.zip
          unzip chromedriver_linux64.zip
          sudo mv chromedriver /usr/local/bin/chromedriver
          sudo chmod +x /usr/local/bin/chromedriver
        # Installs ChromeDriver required by Selenium tests.

      - name: Clone the test repository
        run: |
          git clone https://github.com/serhatozdursun/serhatozdursun-ui-tests.git
        env:
          GITHUB_TOKEN: ${{ secrets.UI_TEST_TOKEN }}
        # Clones the repository containing UI test scripts.

      - name: Install Python dependencies
        working-directory: serhatozdursun-ui-tests
        run: |
          pip install -r requirements.txt
        # Installs Python dependencies required by the UI tests.

      - name: Run tests
        working-directory: serhatozdursun-ui-tests
        id: run_tests
        run: |
          pytest --browser chrome --base_url http://localhost:3000 --html=reports/html/report.html --junitxml=reports/report.xml
        # Executes the UI automation tests using pytest and Selenium.

      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: html-report
          path: serhatozdursun-ui-tests/reports/html
        continue-on-error: true
        # Uploads the HTML report for test results.

      - name: Upload XML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: xml-report
          path: serhatozdursun-ui-tests/reports/report.xml
        continue-on-error: true
        # Uploads the XML report for test results.

Step-by-step summary and objectives:

Checkout Repository:
- Objective: Fetches the latest version of the application code from the repository.
Set up Node.js:
- Objective: Prepares the environment required for Node.js application execution.
Install Dependencies and Build:
- Objective: Installs necessary packages and builds the application to verify code integrity and build stability.
Start the Application:
- Objective: Runs the application locally within the GitHub Actions environment to perform realistic E2E testing.
Set up Python Environment:
- Objective: Configures Python, essential for running Selenium tests.
Install Google Chrome:
- Objective: Provides the browser needed to execute Selenium-based UI automation tests.
Install ChromeDriver:
- Objective: Installs the driver for Selenium to interface with Chrome for browser automation.
Clone Test Repository:
- Objective: Retrieves the latest version of automated UI tests from the dedicated repository.
Install Python Dependencies:
- Objective: Ensures all required libraries and packages are available for the test scripts to run successfully.
Run Tests:
- Objective: Executes Selenium tests against the locally running application, identifying potential UI or functional issues.
Upload HTML Report:
- Objective: Provides an easy-to-read HTML format report for reviewing test results directly from the GitHub interface.
Upload XML Report:
- Objective: Supplies detailed test results in XML format, useful for integration with test management systems or further analysis.

By setting up parallel workflows (one for Chrome, another for Firebase), you achieve effective cross-browser testing for each pull request, running tests in isolated containers before merging to master. This ensures that only thoroughly tested code is merged, significantly reducing potential issues.

Comprehensive Deployment Workflow: Automating Reliable and Efficient Website Deployments

This detailed DevOps automation example illustrates how to reliably deploy code changes to production. The workflow automatically triggers upon merging new code into the main branch, ensuring minimal downtime through structured steps, providing stability and reliability:

Maintenance Mode: Activates maintenance mode to inform users about ongoing updates.
Server Shutdown & Update: Gracefully stops the running server, ensures no residual processes, and pulls the latest code from the repository.
Application Build: Installs dependencies and builds the latest version of the application.
Server Restart: Restarts the application server using PM2 to ensure the application is live again.
Disable Maintenance Mode: Removes the maintenance notification, returning the website to normal operation.

name: Deploy Website

on:
  push:
    branches:
      - main

jobs:
  set_maintenance:
    runs-on: ubuntu-latest
    steps:
      - name: Set maintenance mode
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            touch /var/www/maintenance.flag
            echo "Maintenance mode enabled."

  stop_server:
    runs-on: ubuntu-latest
    needs: set_maintenance
    steps:
      - name: Stop the server and fetch the latest code
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ~/repo/resume
            export PATH=/root/.nvm/versions/node/v23.6.0/bin:$PATH
            nvm alias default 23
            pm2 stop so-website || true
            PID=$(sudo netstat -tulnp | grep :3000 | awk '{print $7}' | cut -d'/' -f1)
            if [ -n "$PID" ]; then
              sudo kill -9 $PID
            fi
            rm -rf .next
            git pull origin main

  build:
    runs-on: ubuntu-latest
    needs: stop_server
    steps:
      - name: Build the app
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ~/repo/resume
            export PATH=/root/.nvm/versions/node/v23.6.0/bin:$PATH
            nvm alias default 23
            yarn install
            yarn build

  start_server:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Start the app
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd ~/repo/resume
            export PATH=/root/.nvm/versions/node/v23.6.0/bin:$PATH
            if ! command -v pm2 &> /dev/null; then
              npm install -g pm2
            fi
            pm2 start yarn --name "so-website" -- start
            pm2 save

  disable_maintenance:
    runs-on: ubuntu-latest
    needs: start_server
    steps:
      - name: Disable maintenance mode
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            rm -f /var/www/maintenance.flag
            echo "Maintenance mode disabled."

Practical Implementation

I've proactively implemented all these GitHub Actions workflows for my personal website (serhatozdursun.com). You can find the repositories here:

Website Repository: serhatozdursun/resume
Test Automation Repository: serhatozdursun-ui-tests

These workflows ensure code quality, robust testing, and seamless deployments, significantly enhancing the overall reliability and maintainability of the project.

Understanding Component Testing: A Practical Guide

Serhat Ozdursun — Thu, 13 Mar 2025 17:25:28 +0000

Introduction

As part of my personal website project, serhatozdursun.com, I have implemented component tests to validate the functionality of various UI elements. You can check out the component test package in my GitHub repository.

This project initially served as a practice ground for improving my TypeScript and DevOps skills. I previously wrote a detailed article on the CI/CD and software development process from a QA perspective, which you can read here. That article was high-level and broad, so I’ve decided to start a new series focusing on specific topics, beginning with component testing.

What is a Component Test?

A component test is a type of front-end test that verifies whether an individual component behaves as expected in isolation. These tests ensure that the UI elements and their interactions function correctly, without requiring the entire application to run.

Key Features of Component Tests:

1. Test a single component in isolation.
3. Simulate user interactions (clicks, form submissions, input validation, etc.).
5. Use mocks and spies to prevent real API calls.
7. Ensure the correct rendering of UI elements.

Writing a Component Test: Example Breakdown

Let's analyze a real example of a component test from my ContactForm component:

import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import '@testing-library/jest-dom';
import ContactForm from '../components/ContactForm';
import userEvent from '@testing-library/user-event';

jest.mock('emailjs-com', () => ({
  send: jest.fn().mockResolvedValue({ text: 'Email sent' }),
}));

describe('ContactForm', () => {
  test('displays error message when email exceeds max length', () => {
    render(<ContactForm />);
    fireEvent.click(screen.getByText('Send a message'));

    fireEvent.change(screen.getByPlaceholderText('Your Email'), {
      target: { value: 'test@test.com'.repeat(10) },
    });

    expect(screen.getByText('Email cannot exceed 50 characters.')).toBeInTheDocument();
  });
});

Breakdown of the Test

Rendering the Component: The render() function mounts the ContactForm component in a virtual DOM.
Simulating User Interaction:
- Clicking the 'Send a message' button.
- Typing an excessively long email ('test@test.com'.repeat(10)).
Checking the Expected Output:
- The test ensures that the correct error message appears ('Email cannot exceed 50 characters.').

This test helps us verify that the form correctly handles validation and displays error messages for incorrect user input.

Component Tests vs. Other Types of Tests

Component testing is distinct from other testing approaches, and understanding these differences is crucial.

❌ What Component Tests Are Not:

❌ Integration Tests → Component tests do not interact with multiple modules or external services like APIs. They focus solely on the behavior of a single component.

❌ End-to-End (E2E) Tests → These tests do not simulate a full user journey within a real browser. Instead, they test components in isolation.

❌ Why Component Tests Are Not Pure Unit Tests:

A pure unit test typically verifies a single function or method in complete isolation, without rendering the UI.

In contrast, component tests render an entire component, meaning they check how multiple elements interact (e.g., inputs, buttons, validation messages).

Since user interactions are simulated, component tests go beyond typical unit testing, though they can still be considered unit tests in the context of UI testing.

✅ Where Component Tests Fit:

To better understand where component tests belong, let’s break down testing levels in software development:

Unit Tests (Lowest Level) 🛠️
- Focuses on individual functions or methods.
- Typically tests pure logic without dependencies.
- Example: Testing a function that formats dates.
Component Tests 🏗️ (Where our focus is!)
- Tests a single UI component in isolation.
- Ensures that a component renders correctly and responds to user interactions.
- Example: Ensuring a form component displays validation errors when invalid input is provided.
Integration Tests 🔗
- Tests interactions between multiple components or external services.
- Verifies that modules communicate correctly.
- Example: Checking if a login form correctly sends credentials to an authentication API.
End-to-End (E2E) Tests (Highest Level) 🌍
- Simulates a real user’s journey through the application.
- Ensures everything works together as expected in a live-like environment.
- Example: Testing an entire checkout process from selecting a product to completing a purchase.

Why Are Component Tests Important?

Component testing offers multiple benefits, including:

Fast Feedback 🚀
- Since components are tested in isolation, these tests run faster than integration or E2E tests.
Early Bug Detection 🐞
- UI bugs are caught before they reach production, reducing costly fixes later.
Ensures UI Stability 🎨
- Helps prevent accidental UI regressions when modifying components.
Improves Developer Confidence ✅
- Developers can make changes without fear of breaking UI functionality.

Conclusion

Component tests are a crucial part of modern front-end testing strategies, ensuring that individual UI elements function as expected. In this article, we explored what component testing is, broke down a real-world example, and compared it with other types of tests.

This is the first article in a new series where I’ll continue diving deeper into testing strategies for front-end development. Stay tuned for more!

If you found this useful, check out my GitHub repo here and my other DevOps and QA articles on Medium. 🚀

Unlocking the Power of Testcontainers: Scalable, Reliable, and Efficient Testing

Serhat Ozdursun — Mon, 10 Mar 2025 11:53:07 +0000

What is Testcontainers?

Testcontainers is a popular open-source library that allows developers to run lightweight, throwaway containers for integration testing. It provides real dependencies, such as databases, message brokers, and browsers, inside Docker containers, ensuring consistency across different environments.

My Experience with Testcontainers

As a test automation engineer, I have used Testcontainers in a TypeScript project with Selenium and Cucumber to improve test reliability and streamline execution in a Bitbucket CI/CD pipeline. It allowed me to run browser tests inside a disposable, isolated environment without worrying about local setup inconsistencies.

By leveraging Testcontainers for Selenium, I could:
Run Chrome browser tests in a containerized environment.
Ensure a clean, fresh browser instance for each test run.
Record executions as MP4 videos for debugging test failures.
Easily integrate with a CI/CD pipeline to maintain consistency across different environments.

Now, let’s dive into how Testcontainers works and why it's a game-changer for integration testing.

Why QA Engineers Love Testcontainers
Testcontainers provides a robust, real-world testing environment that eliminates unreliable test setups. Instead of using mocks or in-memory solutions, QA engineers can leverage real services running in isolated containers.

Key benefits include:

Stable Test Environments: Ensures every test starts with a clean, isolated state, reducing flaky test failures.
Testing with Real Dependencies: Instead of mocks, Testcontainers provides actual databases, message brokers, and browser instances.
Cross-Browser UI Testing: Supports headless and full-browser Selenium tests, ensuring compatibility across environments.
Seamless CI/CD Integration: Runs smoothly in Bitbucket Pipelines, GitHub Actions, and GitLab CI/CD.
MP4 Video Recording for Debugging: With .withRecording(), every browser session can be recorded, helping teams debug failures visually.
Faster Test Feedback with Wait Strategies: Ensures containers fully initialize before tests start, preventing race conditions.
Customizable Environments: QA teams can define test environments using GenericContainer or build custom Dockerfile-based containers.

With Testcontainers, QA teams can run more accurate, reliable, and efficient tests that closely mimic production conditions. 🚀

Types of Containers Supported

Databases: PostgreSQL, MySQL, MongoDB, Redis, etc.
Message Brokers: Kafka, RabbitMQ
Selenium: Running headless browsers for UI testing
Custom Containers: Define your own images and configurations

Wait Strategies
Testcontainers offers several Wait Strategies to ensure that a container is ready before interacting with it. These strategies help avoid race conditions where a test might attempt to use a container before it has fully initialized. Some common wait strategies include:

Wait.forLogMessage(regex, times) – Waits for a specific log message to appear a certain number of times.
Wait.forHealthCheck() – Waits for a container’s health check to return a healthy status.
Wait.forListeningPorts(port) – Ensures that a specific port inside the container is open before proceeding.
Wait.forHttp(path, statusCode) – Waits for an HTTP endpoint to respond with a specific status code.

Example of using a wait strategy in Testcontainers for a PostgreSQL container:

import { GenericContainer, Wait } from "testcontainers";

const container = await new GenericContainer("postgres:latest")
  .withExposedPorts(5432)
  .withEnv("POSTGRES_USER", "testuser")
  .withEnv("POSTGRES_PASSWORD", "testpassword")
  .withWaitStrategy(Wait.forLogMessage("database system is ready to accept connections", 2))
  .start();

Using wait strategies ensures that the container is fully initialized before the test suite begins execution, reducing flakiness in tests.

Building Your Own Images

In addition to using pre-built container images, Testcontainers allows you to build and use custom container images tailored to your test needs. You can create a custom image using GenericContainer and specify a Dockerfile or existing image:

import { GenericContainer } from "testcontainers";

const container = await new GenericContainer("node:latest")
  .withCopyFileToContainer("./my-app", "/usr/src/app")
  .withExposedPorts(3000)
  .withCommand(["npm", "start"])
  .start();

console.log(`Server running at http://localhost:${container.getMappedPort(3000)}`);

This approach is useful when testing applications that require custom dependencies or specific configurations. You can also build an image from a Dockerfile dynamically using withBuild:

const container = await GenericContainer.fromDockerfile("./path/to/Dockerfile").build();

Using Testcontainers in TypeScript

Below is an example of using Testcontainers with Selenium in a TypeScript project for running UI tests in a CI/CD pipeline (e.g., Bitbucket).

Prerequisites

Docker installed on your machine or CI environment.
Node.js and TypeScript installed.
Selenium WebDriver dependencies (selenium-webdriver, @testcontainers/selenium, dotenv, etc.).

Setting Up Testcontainers for Selenium

import * as dotenv from 'dotenv';
import { After, AfterAll, Before, BeforeAll, setDefaultTimeout, Status } from '@cucumber/cucumber';
import { Browser, Builder } from 'selenium-webdriver';
import * as chrome from 'selenium-webdriver/chrome';
import { SeleniumContainer } from '@testcontainers/selenium';

setDefaultTimeout(300000);
export let browser: any;
let container: any;

BeforeAll(async () => {
  dotenv.config();
  container = await new SeleniumContainer('seleniarm/standalone-chromium:latest')
    .withRecording() // Enables video recording of the test execution
    .start();
});

Before(async () => {
  const chromeOptions = new chrome.Options()
    .addArguments('--start-maximized')
    .addArguments('--disable-notifications')
    .addArguments('--no-sandbox')
    .addArguments('--headless');

  browser = await new Builder()
    .forBrowser(Browser.CHROME)
    .setChromeOptions(chromeOptions)
    .usingServer(container.getServerUrl())
    .build();

  await browser.manage().setTimeouts({ implicit: 30000, pageLoad: 120000, script: 30000 });
  await browser.get('https://example.com/login');
  await browser.manage().deleteAllCookies();
});

After(async function (testCase) {
  if (testCase.result?.status === Status.FAILED) {
    const image = await browser.takeScreenshot();
    this.attach(image, 'base64:image/png');
  }

  await browser.quit();
});

AfterAll(async () => {
  const stoppedContainer = await container.stop();
  await stoppedContainer.saveRecording('./image/lastExecution.mp4'); // Saves the execution video
});

Running Testcontainers in a CI/CD Pipeline

Testcontainers integrates seamlessly into Bitbucket Pipelines (or other CI/CD environments) to ensure consistent test execution across different environments. Below is a sample bitbucket-pipelines.yml configuration for running Selenium tests:

image: node:latest
pipelines:
  default:
    - step:
        name: Run Selenium Tests with Testcontainers
        services:
          - docker
        script:
          - npm install
          - npm test

This setup ensures that your tests run inside a Docker-enabled pipeline, leveraging Testcontainers for reliable and isolated test execution.

Conclusion

Testcontainers is a powerful tool that simplifies integration testing by providing real, disposable environments. Whether you're testing databases, message queues, or Selenium-based UI tests, it ensures that tests are reliable and consistent across different environments. Additionally, video recordings of test execution allow for easy debugging and verification, making it a valuable tool for both local development and CI/CD pipelines.

For even more flexibility, building your own images with GenericContainer or fromDockerfile enables custom test environments tailored to your application's needs. Using Wait Strategies ensures that containers are fully initialized before execution, reducing flakiness and improving test stability.

Custom Waiters in Appium: Ensuring Screen Load Before Interaction

Serhat Ozdursun — Wed, 05 Mar 2025 12:49:18 +0000

Why Do We Need Custom Waiters?

In mobile automation with Appium, there are scenarios where standard explicit waits (e.g., elementToBeVisible) are not sufficient. Some elements may be present in the DOM but not fully loaded, especially when dealing with dynamic content updates. A common case is waiting for a specific label or text to appear before proceeding with interactions.

For instance, in a mobile application, a loading screen might disappear, but the main screen elements may still be rendering. If we try to interact with elements too soon, we may encounter NoSuchElementException or StaleElementReferenceException.

A custom waiter can help ensure that the screen is fully loaded before continuing test execution.

Example Scenario
Let's say we have a mobile screen where a title dynamically loads. Instead of just waiting for the element to be present, we should wait until the label is actually populated.

Java Example

public boolean isScreenFullyLoaded() {
    return wait.until(mobileDriver -> {
        String label = mobileDriver.findElementByName(screenTitle).getAttribute("label");
        return !label.isEmpty();
    });
}

How This Helps
Ensures that the screen title has loaded before proceeding.
Avoids false positives where the element exists but is not ready.
Prevents flaky tests by ensuring interactions occur only when the screen is fully rendered.
TypeScript Example (WebdriverIO + Appium)

async function isScreenFullyLoaded(): Promise<boolean> {
    return await browser.waitUntil(async () => {
        const label = await $(`~${screenTitle}`).getAttribute("label");
        return label !== "";
    }, {
        timeout: 10000,
        timeoutMsg: "Screen did not fully load within the expected time"
    });
}

How This Helps
Uses WebdriverIO's waitUntil function to check for the label.
Ensures that the text is present before interacting with the screen.
Provides a timeout message to improve debugging.
Python Example (Appium-Python-Client)

from selenium.webdriver.support.ui import WebDriverWait

def is_screen_fully_loaded(driver):
    return WebDriverWait(driver, 10).until(lambda mobile_driver:  
  mobile_driver.find_element_by_accessibility_id(screen_title).get_attribute("label") != "")

How This Helps

Uses WebDriverWait with a lambda function to check if the label is populated.
Prevents interacting with elements before they are fully rendered.
Reduces flakiness in mobile automation.

Conclusion
Using a custom waiter like this improves test stability by ensuring that elements are not just present but fully loaded and ready for interaction. This approach is particularly useful when dealing with dynamically loaded content in mobile applications.

DEV Community: Serhat Ozdursun

Shipping AI into Your CI: Coverage-Aware Reviews with Danger + OpenAI (and SonarCloud)

What you get

Architecture (bird’s eye)

Why this pattern?

The dangerfile.ts — what it actually does

1) Coverage gate on changed code

2) AI unit test suggestions (copy-paste ready)

3) AI code review (snippet-first + optional inline)

“Knobs” behind Secrets (and not just on GitHub)

Optional hardening

Rollout plan

Final thoughts

🧪 GitHub Actions Matrix Strategy - Part 2: Email Notifications with Artifact Links via EmailJS

📬 Why Use EmailJS?

💡 What is EmailJS?

🛠 Other Tools You Could Use

✅ Why I Chose EmailJS

📄 Dynamic Email Templates in EmailJS

⚙️ Updated GitHub Actions Workflow (with EmailJS Integration)

✅ Success Email Step

❌ Failure Email Step

📬 Real Email Example

🎁 Final Thoughts

🧩 What’s Next?

🧪 GitHub Actions Matrix Strategy - Part 2: Send Email Notifications with Test Artifacts

📬 Why Use EmailJS?

💡 What is EmailJS?

🛠 Other Tools You Could Use

✅ Why I Chose EmailJS

📄 Dynamic Email Templates in EmailJS

What is GitHub Actions Matrix Strategy?

Cross-Browser UI Testing with GitHub Actions Matrix Strategy

🔍 Key Differences in the Old Files

This setup worked, but had several downsides:

The Solution: Matrix Strategy

Before vs After

Final Thoughts

Java Checkstyle Tool: Enforce Coding Standards with Ease

What is Checkstyle?

Key Features

Getting Started

For Maven Projects

For Gradle Projects

Built-in or Custom Rules

Prevent Thread.sleep()

Prevent By.xpath(...)

Prevent System.out.println

Running Checkstyle

GitHub Actions CI Integration

IDE Support

Final Thoughts

Streamlining Software Development with GitHub Actions: Automation, Testing, and Deployment

Example: Static Code Analysis with CodeQL

Using GitHub Actions for QA Automation

Step-by-step summary and objectives:

Comprehensive Deployment Workflow: Automating Reliable and Efficient Website Deployments

Practical Implementation

Understanding Component Testing: A Practical Guide

Unlocking the Power of Testcontainers: Scalable, Reliable, and Efficient Testing

Custom Waiters in Appium: Ensuring Screen Load Before Interaction

The `dangerfile.ts` — what it actually does

Prevent `Thread.sleep()`

Prevent `By.xpath(...)`

Prevent `System.out.println`