Automating Testing with GitHub Actions: Continuous Integration (CI) Part 2

mioumiou
6 min readMay 9, 2024

--

In our previous article, we discussed various techniques for setting up CI workflows using GitHub Actions, focusing on best practices to enhance the quality of software development processes. Building upon that, today we delve deeper into two distinct Testing Strategies aligned with the branching strategies used by the development team. We will use two main branching workflows: Feature Branch and Gitflow Workflows. Based on those we will also describe the Testing Strategy for each by including:

  • Testing levels that should be covered based on best practices
  • Where these testing levels should lie
  • Propose different YAML files for GitHub workflows, and how they can be interconnected

Feature Branch Workflow Testing

This strategy involves creating dedicated branches for each feature being developed.

Feature Branch Workflow

Here’s how we align QA testing practices with this approach:

Testing Levels and Coverage

Unit and integration tests are typically handled by developers. For QA testing, we focus on higher-level testing, including API tests, UI tests, security tests, and manual User Acceptance Testing (UAT).

Testing Workflow

  • Before Merge: API tests, UI tests, and security tests are triggered automatically upon each push to the feature branch.
  • In PR: Results of these tests are reported back within the pull request for review by the development and QA teams.
  • Branches: All testing levels are executed on the feature branch itself.
  • Automation: Tests are automatically triggered upon each push to the feature branch, ensuring timely feedback.
  • Manual Trigger: Manual UAT is performed by the QA team, and initiated upon completion of automated tests and readiness for human validation.

In case you want to find out more about Feature Branch Workflow, we will provide some extra resources at the end of the article.

YAML Files

And now it’s the time to connect all these with our Github Actions! You will notice the differences in the YAML files: Unit/Integration Tests run on push. API, Contract Testing, UI Testing & Security Testing are running on Pull Request sequentially, ensuring that we will not move to UI Testing if some of our API tests are failing, and making our CI Pipeline fail fast.

Unit And Integration Tests

name: Unit and Integration Tests
on:
push:
branches:
- feature/*
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run unit tests
run: |
# Command to run unit tests
- name: Run integration tests
run: |
# Command to run integration tests

API Tests and Contract Testing

name: API Tests and Contract Testing
on:
pull_request:
branches:
- feature/*
jobs:
test:
runs-on: ubuntu-latest
needs: [unit-integration-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run API tests
run: |
# Command to run API tests
- name: Run contract tests
run: |
# Command to run contract tests

UI Tests

name: UI Tests
on:
pull_request:
branches:
- feature/*
jobs:
test:
runs-on: ubuntu-latest
needs: [api-contract-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run UI tests
run: |
# Command to run UI tests

Security Tests

name: Security Tests
on:
pull_request:
branches:
- feature/*
jobs:
test:
runs-on: ubuntu-latest
needs: [ui-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run security tests
run: |
# Command to run security tests

Deployment of Testing Environment

Now that our application has been fully tested, we are confident enough to deploy a testing environment for UAT Manual testing to take place.

name: Deploy Testing Environment
on:
pull_request:
branches:
- feature/*
jobs:
deploy:
runs-on: ubuntu-latest
needs: [security-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Deploy testing environment
run: |
# Command to deploy testing environment

Git-flow Workflow Testing

In this approach, Git-flow Workflow, the development process is structured around two main branches: master and develop.

Let’s align QA testing practices with this workflow:

Testing Levels and Coverage

Similar to the Feature Branch Strategy, QA testing focuses on API tests, UI tests, security tests, and manual UAT.

Testing Workflow

  • Before Merge: API tests, UI tests, and security tests run automatically on the develop branch.
  • In PR: Results of these tests are reported back within the pull request for review before merging into the develop branch.
  • Branches: Testing levels are executed primarily on the develop branch to ensure the stability of the main development branch.
  • Automation: Automated tests are triggered upon each pull request to the develop branch, maintaining the integrity of ongoing development efforts.
  • Manual Trigger: Manual UAT is conducted by the QA team as a final validation step before merging into the master branch for production release.

Unit and Integration Tests

name: Unit and Integration Tests
on:
push:
branches:
- feature/*
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run unit tests
run: |
# Command to run unit tests
- name: Run integration tests
run: |
# Command to run integration tests

API tests & Contract Testing

name: API Tests and Contract Testing
on:
pull_request:
branches:
- develop
jobs:
test:
runs-on: ubuntu-latest
needs: [unit-integration-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run API tests
run: |
# Command to run API tests
- name: Run contract tests
run: |
# Command to run contract tests

UI Tests

name: UI Tests
on:
pull_request:
branches:
- develop
jobs:
test:
runs-on: ubuntu-latest
needs: [api-contract-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run UI tests
run: |
# Command to run UI tests

Security Tests

name: Security Tests
on:
pull_request:
branches:
- develop
jobs:
test:
runs-on: ubuntu-latest
needs: [ui-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run security tests
run: |
# Command to run security tests

Deploy Testing Environment

name: Deploy Testing Environment
on:
pull_request:
branches:
- develop
jobs:
deploy:
runs-on: ubuntu-latest
needs: [security-tests]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Deploy testing environment
run: |
# Command to deploy testing environment

As you can see, the YAML files for Git-flow Workflow are similar to those of the Feature Branch Strategy, with the only difference being the branches specified in the on section, which is adjusted to match the develop branch instead of feature/*.

In case you want to find out more about Git-flow Workflow, we will provide some extra resources at the end of the article.

Lessons Learnt

We have created two strong testing strategies aligning with two modern branching strategies. By combining the YAML files with the previous article’s best practices, I believe you will have a fast, strong CI Pipeline and the confidence that your application has high quality.

ΝΟΤΕ: Please keep in mind that each application is different, and the automation testing strategies discussed here may need to be tailored to suit the specific requirements and characteristics of individual projects. It’s essential to adapt these strategies judiciously to maximize their effectiveness in your development environment. Cheers

Resources

Tiburg Science Hub: Git Branching Strategies

Atlassian Git Tutorial: Feature Branch

Atlassian Git Tutorial: Git-flow

--

--