Introduction

Running all Python unit tests in a directory is usually a test-discovery problem, not a loop-writing problem. The tool walks the directory tree, finds files that match its naming rules, imports them, and executes the discovered tests. In Python, the two most common ways to do this are the built-in unittest discovery command and pytest.

If you want the standard-library answer, use python -m unittest discover. If the project already uses pytest, run pytest against the target directory instead. The right choice depends on the test framework the repository is already using.

Use unittest Discovery

Python's built-in unittest module can discover tests recursively from a starting directory.

python -m unittest discover -s tests -p 'test*.py'

The flags mean:

• '-s tests sets the start directory'
• '-p 'test*.py' defines the filename pattern'

If your tests follow the default naming conventions, even this may be enough:

python -m unittest discover

A simple layout might look like this:

1project/
2  app/
3  tests/
4    test_math.py
5    test_api.py

And a minimal test file:

1import unittest
2
3class MathTests(unittest.TestCase):
4    def test_addition(self):
5        self.assertEqual(2 + 2, 4)
6
7if __name__ == "__main__":
8    unittest.main()

Use pytest If the Project Already Depends on It

Many Python projects use pytest because it has simpler test syntax and richer reporting.

pytest tests/

Or just run it from the project root:

pytest

A pytest test can be very small:

def test_addition():
    assert 2 + 2 == 4

pytest will also run many unittest.TestCase tests, which makes it a good bridge when a codebase is gradually modernizing its tests.

Run Tests From the Correct Working Directory

Test discovery depends on imports working. The safest habit is to run the command from the project root so the package layout matches what the tests expect.

For example:

cd /path/to/project
python -m unittest discover -s tests -p 'test*.py'

If you run discovery from the wrong directory, Python may fail to import the application package or may discover the wrong files.

Narrow or Expand What Gets Discovered

You can control scope by changing the start directory or pattern.

Run only API tests with unittest:

python -m unittest discover -s tests/api -p 'test*.py'

Run only files matching a custom pattern:

python -m unittest discover -s tests -p '*_spec.py'

This is useful when the repository separates unit, integration, and end-to-end suites into different folders.

Keep Naming and Imports Consistent

Discovery works best when the project follows clear conventions. Common patterns are:

• test files named test_*.py
• test classes inheriting from unittest.TestCase
• test methods named test_*
• packages structured so imports work from the project root

The more predictable the layout, the less time you spend debugging discovery behavior.

Common Pitfalls

The most common mistake is running discovery from the wrong directory and then chasing import errors that are really path issues.

Another issue is mixing frameworks without noticing. A repository may contain pytest tests, unittest tests, or both, and the command should match the project.

A third problem is using a filename pattern that does not match the actual test files, which makes it look as though there are no tests to run.

Summary

• Use python -m unittest discover for the standard-library test discovery workflow.
• Use pytest when the repository already depends on pytest conventions or plugins.
• Run the command from the project root so imports resolve correctly.
• Adjust the start directory and filename pattern to control which tests are discovered.
• Keep naming conventions consistent so discovery works predictably.