cicd-testing-integration
Skill5 starsChanged 9 months agoMITView on GitHub
Integrate automated tests into CI/CD pipelines for continuous testing, including pipeline configuration, test automation strategies, reporting, and DevOps collaboration.
- Reads credentials
In this repository10 other files it gives its agents.
- browser-useSkill
- defect-lifecycle-managerSkill
- find-skillsSkill
- multi-agent-orchestrationSkill
- qa-process-improvementSkill
- skill-creatorSkill
- test-design-istqbSkill
- test-execution-managerSkill
- user-story-static-verifierSkill
- senior-qa-engineerSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this skill when you need to:
- Distinctive: line 16
Create test reporting dashboards
- Distinctive: line 210
Run most critical tests first
- Distinctive: line 219
No flaky tests in pipeline
- Distinctive: line 231
Run affected tests only
- Distinctive: line 385
Test execution time trends
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CI/CD Testing Integration
Expert skill for integrating automated testing into CI/CD pipelines and enabling continuous quality feedback.
When to Use
Use this skill when you need to:
- Set up test automation in CI/CD pipelines
- Configure automated test execution
- Implement continuous testing strategy
- Create test reporting dashboards
- Optimize pipeline performance
- Enable shift-left testing
CI/CD Testing Strategy
Test Pyramid for CI/CD
/\
/UI\ 10% - E2E/UI Tests (slow, brittle)
/────\
/ API \ 30% - Integration/API Tests
/────────\
/ UNIT \ 60% - Unit Tests (fast, stable)
/────────────\Principle: More fast tests at bottom, fewer slow tests at top
Continuous Testing Stages
1. Pre-Commit
- Unit tests (developer runs)
- Linting/static analysis
2. Commit Stage (Fast - <5 min)
- Unit tests
- Basic smoke tests
- Code coverage check
3. Acceptance Stage (Medium - 15-30 min)
- Integration tests
- API tests
- Component tests
4. Deployment Stage (Slower - 30-60 min)
- E2E tests
- Security scans
- Performance tests
5. Production Monitoring
- Synthetic tests
- Health checks
- User monitoringPipeline Configuration Examples
GitHub Actions
name: CI Testing Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
unit-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Install dependencies
run: npm ci
- name: Run unit tests
run: npm run test:unit
- name: Check coverage
run: npm run test:coverage
- name: Upload coverage
uses: codecov/codecov-action@v3
integration-tests:
needs: unit-tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Start services
run: docker-compose up -d
- name: Run integration tests
run: npm run test:integration
- name: Stop services
run: docker-compose down
e2e-tests:
needs: integration-tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Playwright
run: npx playwright install --with-deps
- name: Run E2E tests
run: npm run test:e2e
- name: Upload test results
if: always()
uses: actions/upload-artifact@v3
with:
name: playwright-report
path: playwright-report/Jenkins Pipeline
pipeline {
agent any
stages {
stage('Unit Tests') {
steps {
sh 'npm run test:unit'
}
post {
always {
junit 'test-results/unit/*.xml'
}
}
}
stage('Integration Tests') {
steps {
sh 'docker-compose up -d'
sh 'npm run test:integration'
}
post {
always {
sh 'docker-compose down'
junit 'test-results/integration/*.xml'
}
}
}
stage('E2E Tests') {
when {
branch 'main'
}
steps {
sh 'npm run test:e2e'
}
post {
always {
publishHTML([
reportDir: 'playwright-report',
reportFiles: 'index.html',
reportName: 'E2E Test Report'
])
}
}
}
stage('Deploy to QA') {
when {
branch 'develop'
}
steps {
sh './deploy-qa.sh'
}
}
}
post {
failure {
mail to: 'qa-team@company.com',
subject: "Pipeline Failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
body: "Check ${env.BUILD_URL}"
}
}
}Test Automation Best Practices
1. Fast Feedback
- Unit tests: < 5 minutes
- Integration tests: < 15 minutes
- E2E tests: < 30 minutes
- Run most critical tests first
2. Test Independence
- Tests don't depend on each other
- Can run in any order
- Can run in parallel
- Clean state before/after each test
3. Stable Tests
- No flaky tests in pipeline
- Quarantine unstable tests
- Fix or remove, don't ignore
- Monitor flake rate
4. Meaningful Failures
- Clear error messages
- Attach screenshots/logs
- Show exact failure point
- Link to relevant code
5. Selective Execution
- Run affected tests only
- Full regression nightly
- Smoke tests on every commit
- Performance tests weekly
Test Reporting & Dashboards
Test Results Format
{
"summary": {
"total": 250,
"passed": 245,
"failed": 3,
"skipped": 2,
"duration": "12m 34s",
"passRate": "98%"
},
"failures": [
{
"test": "Login with invalid password",
"error": "Expected 401, got 500",
"screenshot": "failure-1.png",
"trace": "error.log"
}
]
}Dashboard Metrics
Track and display:
- ✓ Build Success Rate: Passing builds / Total builds
- ✓ Test Pass Rate: Passing tests / Total tests
- ✓ Code Coverage: Lines covered / Total lines
- ✓ Build Duration: Average time per stage
- ✓ Flaky Test Rate: Inconsistent tests / Total
- ✓ MTTR: Mean time to repair failing builds
Alerting Rules
Critical Alerts:
- Build fails on main branch → Slack + Email
- Test pass rate < 95% → Team notification
- Security vulnerability found → Immediate action
Warning Alerts:
- Build duration > 30 minutes → Optimize
- Code coverage decreased → Review
- Flaky test detected → InvestigateOptimization Strategies
Parallel Execution
# Parallelize test suites
jobs:
test:
strategy:
matrix:
shard: [1, 2, 3, 4]
steps:
- run: npm run test:e2e -- --shard=${{ matrix.shard }}/4Caching Dependencies
- name: Cache dependencies
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}Smart Test Selection
# Only run tests affected by changes
changed_files=$(git diff --name-only HEAD~1)
npm run test:selective --files="$changed_files"Docker Layer Caching
# Optimize Docker builds
FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
# Dependencies cached hereEnvironment Management
Test Environments
Development → Integration → QA → Staging → Production
↓ ↓ ↓ ↓ ↓
Unit Tests API Tests E2E Tests Smoke MonitoringConfiguration Management
// config/test.env.js
module.exports = {
qa: {
apiUrl: 'https://api-qa.company.com',
dbHost: 'db-qa.company.com'
},
staging: {
apiUrl: 'https://api-staging.company.com',
dbHost: 'db-staging.company.com'
}
};Integration Patterns
1. Pull Request Validation
PR Created → Run unit & integration tests
→ Pass? Merge allowed : Block merge2. Continuous Deployment
Commit → Build → Test → Deploy QA → E2E Tests → Deploy Staging3. Nightly Regression
Scheduled: 2 AM → Full test suite → Report to team4. On-Demand Testing
Manual Trigger → Select test suite → Run → Report resultsMonitoring & Maintenance
Pipeline Health
Monitor:
- Build failure trends
- Test execution time trends
- Infrastructure costs
- Resource utilization
Test Maintenance
Regular activities:
- Remove obsolete tests
- Update flaky tests
- Optimize slow tests
- Review test coverage
- Update test data
Best Practices
- ✓ Keep pipelines fast (< 10 min for commit stage)
- ✓ Fail fast (run fastest tests first)
- ✓ Run tests in parallel when possible
- ✓ Use containers for consistency
- ✓ Version control everything (code, tests, configs)
- ✓ Secure secrets and credentials
- ✓ Monitor and optimize continuously
- ✓ Make failures visible and actionable
- ✓ Automate as much as possible
- ✓ Collaborate with DevOps team
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

