What if you could catch bugs the moment they appear, without lifting a finger?
Why Continuous testing in CI/CD in Testing Fundamentals? - Purpose & Use Cases
Imagine you are building a big LEGO set with friends. Every time someone adds a piece, you have to stop and check if the whole structure still stands strong. Doing this by hand every time takes forever and slows everyone down.
Manually testing software after every change is slow and tiring. It's easy to miss mistakes, and fixing problems late means more work and frustration. This slows down the whole team and delays delivering new features.
Continuous testing in CI/CD means running tests automatically every time code changes. This catches problems early, saves time, and keeps the project moving smoothly without waiting for long manual checks.
Make code changes
Run tests manually
Fix bugs if found
RepeatMake code changes Push to repository Tests run automatically Get instant feedback
It lets teams deliver better software faster by catching errors early and keeping quality high without slowing down progress.
A team working on a mobile app uses continuous testing to automatically check every update. This way, they quickly find and fix bugs before users see them, making the app reliable and enjoyable.
Manual testing after every change is slow and error-prone.
Continuous testing runs tests automatically with every code update.
This speeds up development and improves software quality.
Practice
Solution
Step 1: Understand continuous testing concept
Continuous testing means running tests automatically during the CI/CD process.Step 2: Identify the purpose in CI/CD
Its goal is to catch bugs early by testing every code change automatically.Final Answer:
To automatically run tests on every code change -> Option AQuick Check:
Continuous testing = automatic tests on code changes [OK]
- Thinking testing is manual only
- Believing tests run after deployment
- Assuming testing happens only once at release
Solution
Step 1: Recall shell command syntax
To run a shell script, the correct command is 'sh scriptname.sh'.Step 2: Check each option
sh tests.sh uses 'sh tests.sh' which correctly runs the script. Others are invalid shell commands.Final Answer:
sh tests.sh -> Option AQuick Check:
Shell script run = sh script.sh [OK]
- Using 'run' or 'start' which are not shell commands
- Forgetting to use 'sh' before script name
- Confusing shell commands with other languages
steps:
- name: Run tests
run: |
echo "Starting tests"
pytest tests/
echo "Tests done"What will be the output if all tests pass?
Solution
Step 1: Analyze the commands in order
The pipeline runs 'echo "Starting tests"', then 'pytest tests/', then 'echo "Tests done"'.Step 2: Understand output if tests pass
If pytest runs successfully, it outputs test results but here we focus on echo commands output. So output includes 'Starting tests' then 'Tests done'.Final Answer:
Starting tests\nTests done -> Option CQuick Check:
Echo commands print start and done messages [OK]
- Assuming pytest output is shown instead of echo
- Mixing order of printed lines
- Thinking tests failed without error
sh: pytest: command not found. What is the most likely cause?Solution
Step 1: Interpret the error message
The error 'sh: pytest: command not found' means the shell cannot find the pytest command.Step 2: Identify cause in CI environment
This usually means pytest is not installed or not in PATH in the pipeline environment.Final Answer:
pytest is not installed in the pipeline environment -> Option DQuick Check:
Command not found = missing installation [OK]
- Assuming syntax error causes command not found
- Thinking missing tests directory causes this error
- Believing pipeline skipped the step without error
src/ directory. Which approach best achieves this?Solution
Step 1: Understand conditional testing in CI/CD
To save time, tests should run only when relevant code changes occur.Step 2: Apply file path filters in pipeline configuration
Configuring the pipeline to detect changes insrc/and run tests only then is the best approach.Final Answer:
Configure the pipeline to run tests only when files insrc/change -> Option BQuick Check:
Run tests conditionally based on changed files [OK]
- Running tests every time wastes resources
- Testing only after deployment delays bug detection
- Manual triggers reduce automation benefits
Ready to prove it?
Pass the test and this pattern moves unknown
