Automating Testing with GitHub Actions: Continuous Integration (CI) Part 2
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.
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