core-tests 2.0.5__tar.gz → 2.2.0__tar.gz

{core_tests-2.0.5 → core_tests-2.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: core-tests
-Version: 2.0.5
+Version: 2.2.0
 Summary: It contains common elements for testing purposes...
 Author-email: Alejandro Cora González <alek.cora.glez@gmail.com>
 Maintainer: Alejandro Cora González
@@ -23,29 +23,39 @@ Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Classifier: Programming Language :: Python :: 3.14
+Classifier: Programming Language :: Python :: Implementation :: PyPy
 Requires-Python: >=3.9
 Description-Content-Type: text/x-rst
 License-File: LICENSE
 Requires-Dist: click>=8.1.8
 Requires-Dist: coverage>=7.7.1
 Requires-Dist: environs>=14.1.1
-Requires-Dist: pytest>=7.4.0
-Requires-Dist: pytest-xdist>=3.5.0
 Provides-Extra: dev
-Requires-Dist: core-dev-tools>=1.2.1; extra == "dev"
+Requires-Dist: core-dev-tools>=2.1.0; extra == "dev"
 Dynamic: license-file
 
 core-tests
 ===============================================================================
 
-This project contains basic elements for testing purposes and the ability 
-to run (via console commands) tests and code coverage (unittest-based). This way, we can 
-stick to the `DRY -- Don't Repeat Yourself` principle and avoid code duplication
-in each python project where tests coverage and tests execution are
-expected...
+A reusable library that provides CLI commands for running ``unittest``-based
+tests and generating code coverage reports. It wraps Python's built-in
+``unittest`` framework and ``coverage`` into a ``Click`` command group so
+consuming projects can use ``python manager.py run-tests`` and
+``python manager.py run-coverage`` without duplicating that logic across
+every project in the ecosystem.
+
+This library is intentionally scoped to ``unittest`` and ``coverage``.
+If your project requires ``pytest``-specific features (fixtures, parametrize,
+plugins, parallel execution), install ``pytest`` directly or via
+``core-dev-tools`` and invoke it standalone — it is a better fit for that use
+case than routing it through this abstraction layer.
 
 ===============================================================================
 
+.. image:: https://static.pepy.tech/personalized-badge/core-tests?period=total&units=INTERNATIONAL_SYSTEM&left_color=BLACK&right_color=GREEN&left_text=downloads
+    :target: https://pepy.tech/projects/core-tests
+    :alt: PyPI Downloads
+
 .. image:: https://img.shields.io/pypi/pyversions/core-tests.svg
     :target: https://pypi.org/project/core-tests/
     :alt: Python Versions
@@ -83,21 +93,34 @@ Install from PyPI using pip:
 Features
 ===============================================================================
 
-* **Dual Test Engine Support**: Run tests using either `unittest` or `pytest` frameworks
-* **Flexible Test Discovery**: Supports multiple file patterns:
-    - `test_*.py` (standard pattern)
-    - `*_test.py` (alternative pattern)
-    - `tests_*.py` (custom pattern)
-* **Custom Pattern Support**: Specify custom file patterns using the `--pattern` flag
-* **Test Organization**: Run tests by type (unit, integration, functional, etc.)
-* **Coverage Reports**: Generate coverage reports with both frameworks
-* **CLI Integration**: Easy integration via Click command collections
+* **Unified CLI abstraction**: Expose ``run-tests`` and ``run-coverage`` in any
+  project without duplicating boilerplate — just wire ``cli_tests`` into your
+  ``CommandCollection``.
+* **Flexible Test Discovery**: Supports multiple file patterns out of the box:
+
+    - ``test_*.py`` (standard pattern)
+    - ``*_test.py`` (alternative pattern)
+    - ``tests_*.py`` (custom pattern)
+
+* **Custom Pattern Support**: Override discovery with ``--pattern`` for
+  non-standard file layouts.
+* **Enforced Coverage**: ``run-coverage`` applies the ``fail_under`` setting of
+  your coverage configuration, or ``--fail-under`` for a single run, and exits
+  non-zero when the total is below it.
+* **CI-ready Reports**: Writes ``coverage.xml`` (Cobertura, relative paths)
+  beside the HTML report, so a CI platform can annotate a merge request diff.
+* **Test Organization**: Target specific test directories (unit, integration,
+  functional, etc.) via ``--test-type``.
+* **Branch Coverage Reports**: Generate branch-level coverage reports and
+  optional HTML output.
+* **DRY principle**: One implementation shared across all projects in the
+  ecosystem.
 
 
 How to Use
 ===============================================================================
 
-Create a ``manager.py`` file in your project root to integrate 
+Create a ``manager.py`` file in your project root to integrate
 the test commands:
 
 .. code-block:: python
@@ -112,7 +135,7 @@ the test commands:
 
 This setup provides two commands:
 
-* ``run-tests``: Execute test suites with unittest or pytest
+* ``run-tests``: Execute unittest-based test suites
 * ``run-coverage``: Generate code coverage reports
 
 Example usage:
@@ -120,7 +143,7 @@ Example usage:
 .. code-block:: bash
 
     python manager.py run-tests --test-type unit
-    python manager.py run-coverage --engine pytest
+    python manager.py run-coverage
 
 
 Available Commands
@@ -129,49 +152,56 @@ Available Commands
 run-tests
 -------------------------------------------------------------------------------
 
-Execute test suites with flexible options:
+Execute unittest-based test suites with flexible options:
 
 **Options:**
 
-* ``--engine``: Test engine to use (``unittest`` or ``pytest``). Default: ``unittest``
-* ``--test-type``: Folder name under ``./tests`` directory (e.g., ``unit``, ``integration``, ``functional``)
-* ``--pattern``: File pattern to match test files (e.g., ``*.py``, ``test_*.py``). Works with both engines.
+* ``--test-type``: Folder name under ``./tests`` directory (e.g., ``unit``,
+  ``integration``, ``functional``). Default: ``unit``
+* ``--pattern``: File pattern to match test files (e.g., ``*.py``,
+  ``test_*.py``). Defaults to multi-pattern discovery.
 
 **Examples:**
 
 .. code-block:: bash
 
-    # Run unit tests with unittest (default)
+    # Run unit tests (default)
     python manager.py run-tests --test-type unit
 
-    # Run integration tests with pytest
-    python manager.py run-tests --engine pytest --test-type integration
+    # Run integration tests
+    python manager.py run-tests --test-type integration
 
-    # Run tests with custom pattern
-    python manager.py run-tests --test-type functional --pattern "test_*.py"
+    # Run tests with a custom file pattern
+    python manager.py run-tests --test-type functional --pattern "*.py"
 
-    # Run all tests in a custom folder
+    # Run tests in a custom folder
     python manager.py run-tests --test-type "custom_folder"
 
 
 run-coverage
 -------------------------------------------------------------------------------
 
-Generate code coverage reports:
+Generate code coverage reports across all test directories:
 
 **Options:**
 
-* ``--engine``: Test engine to use (``unittest`` or ``pytest``). Default: ``unittest``
+* ``--save-report``: Save HTML, XML and data coverage reports to disk.
+  Default: ``True``
+* ``--fail-under``: Minimum total coverage percentage. Exits non-zero below it,
+  and takes precedence over the ``fail_under`` setting of the coverage
+  configuration. Default: unset, so the configured value applies.
 
 **Examples:**
 
 .. code-block:: bash
 
-    # Generate coverage with unittest
     python manager.py run-coverage
+    python manager.py run-coverage --save-report false
+    python manager.py run-coverage --fail-under 90
 
-    # Generate coverage with pytest
-    python manager.py run-coverage --engine pytest
+The HTML report lands in ``htmlcov/``, and a Cobertura ``coverage.xml`` beside
+it, with paths relative to the working directory so a CI platform can map them
+onto the repository.
 
 
 Quick Start
@@ -213,78 +243,32 @@ Tests and Coverage
 
     python manager.py run-tests --test-type unit
     python manager.py run-tests --test-type integration
-    python manager.py run-tests --test-type "another folder that contains test cases under ./tests"
     python manager.py run-tests --test-type functional --pattern "*.py"
+    python manager.py run-coverage
 
 
-Using PyTest
+Using pytest directly
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The `unittest` framework cannot discover or run pytest-style tests, it is designed to
-discover and run tests that are subclasses of `unittest.TestCase` and follow its
-conventions. Pytest-style tests (i.e., functions named test_* that are not inside a
-`unittest.TestCase` class, or tests using pytest fixtures, parametrize, etc.) are not
-recognized by unittest's discovery mechanism, `unittest` will simply ignore standalone
-test functions and any pytest-specific features...
-
-That's why you can use PyTest if required.
+``unittest`` cannot discover standalone ``test_*`` functions or use pytest
+fixtures. If your project relies on those features, invoke ``pytest`` directly:
 
 .. code-block:: bash
 
-    python manager.py run-tests --engine pytest
+    pytest tests/unit/
+    pytest -n auto --cov=your_package --cov-report=html
 
-..
-
-Test coverage
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Install ``pytest`` via ``pip`` or through ``core-dev-tools``:
 
 .. code-block:: bash
 
-    python manager.py run-coverage                          # For `unittest` framework...
-    python manager.py run-coverage --engine pytest          # For `PyTest`...
-    pytest -n auto --cov=core_tests --cov-report=html       # Direct `pytest` execution...
+    pip install pytest pytest-xdist pytest-cov
+    # or
+    pip install ".[dev]"  # if core-dev-tools includes pytest
 
 ..
 
 
-Best Practices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When working with pytest, consider these optimization strategies:
-
-1. **Use parallel execution for independent tests:**
-
-   .. code-block:: bash
-
-       pytest -n auto
-
-   ..
-
-2. **Run fast unit tests first during development:**
-
-   .. code-block:: bash
-
-       pytest tests/unit/ -n auto
-
-   ..
-
-3. **Run functional tests with limited parallelism:**
-
-   .. code-block:: bash
-
-       pytest tests/functional/ -n 2  # Avoid AWS rate limits
-
-   ..
-
-4. **Use markers to run specific test subsets:**
-
-   .. code-block:: bash
-
-       pytest -m "unit and not slow" -n auto
-
-   ..
-
-
 Contributing
 ===============================================================================
 
@@ -293,7 +277,7 @@ Contributions are welcome! Please:
 1. Fork the repository
 2. Create a feature branch
 3. Write tests for new functionality
-4. Ensure all tests pass: ``pytest -n auto``
+4. Ensure all tests pass: ``python manager.py run-tests --test-type unit``
 5. Run linting: ``pylint core_tests``
 6. Run security checks: ``bandit -r core_tests``
 7. Submit a pull request

{core_tests-2.0.5 → core_tests-2.2.0}/README.rst

@@ -1,14 +1,25 @@
 core-tests
 ===============================================================================
 
-This project contains basic elements for testing purposes and the ability 
-to run (via console commands) tests and code coverage (unittest-based). This way, we can 
-stick to the `DRY -- Don't Repeat Yourself` principle and avoid code duplication
-in each python project where tests coverage and tests execution are
-expected...
+A reusable library that provides CLI commands for running ``unittest``-based
+tests and generating code coverage reports. It wraps Python's built-in
+``unittest`` framework and ``coverage`` into a ``Click`` command group so
+consuming projects can use ``python manager.py run-tests`` and
+``python manager.py run-coverage`` without duplicating that logic across
+every project in the ecosystem.
+
+This library is intentionally scoped to ``unittest`` and ``coverage``.
+If your project requires ``pytest``-specific features (fixtures, parametrize,
+plugins, parallel execution), install ``pytest`` directly or via
+``core-dev-tools`` and invoke it standalone — it is a better fit for that use
+case than routing it through this abstraction layer.
 
 ===============================================================================
 
+.. image:: https://static.pepy.tech/personalized-badge/core-tests?period=total&units=INTERNATIONAL_SYSTEM&left_color=BLACK&right_color=GREEN&left_text=downloads
+    :target: https://pepy.tech/projects/core-tests
+    :alt: PyPI Downloads
+
 .. image:: https://img.shields.io/pypi/pyversions/core-tests.svg
     :target: https://pypi.org/project/core-tests/
     :alt: Python Versions
@@ -46,21 +57,34 @@ Install from PyPI using pip:
 Features
 ===============================================================================
 
-* **Dual Test Engine Support**: Run tests using either `unittest` or `pytest` frameworks
-* **Flexible Test Discovery**: Supports multiple file patterns:
-    - `test_*.py` (standard pattern)
-    - `*_test.py` (alternative pattern)
-    - `tests_*.py` (custom pattern)
-* **Custom Pattern Support**: Specify custom file patterns using the `--pattern` flag
-* **Test Organization**: Run tests by type (unit, integration, functional, etc.)
-* **Coverage Reports**: Generate coverage reports with both frameworks
-* **CLI Integration**: Easy integration via Click command collections
+* **Unified CLI abstraction**: Expose ``run-tests`` and ``run-coverage`` in any
+  project without duplicating boilerplate — just wire ``cli_tests`` into your
+  ``CommandCollection``.
+* **Flexible Test Discovery**: Supports multiple file patterns out of the box:
+
+    - ``test_*.py`` (standard pattern)
+    - ``*_test.py`` (alternative pattern)
+    - ``tests_*.py`` (custom pattern)
+
+* **Custom Pattern Support**: Override discovery with ``--pattern`` for
+  non-standard file layouts.
+* **Enforced Coverage**: ``run-coverage`` applies the ``fail_under`` setting of
+  your coverage configuration, or ``--fail-under`` for a single run, and exits
+  non-zero when the total is below it.
+* **CI-ready Reports**: Writes ``coverage.xml`` (Cobertura, relative paths)
+  beside the HTML report, so a CI platform can annotate a merge request diff.
+* **Test Organization**: Target specific test directories (unit, integration,
+  functional, etc.) via ``--test-type``.
+* **Branch Coverage Reports**: Generate branch-level coverage reports and
+  optional HTML output.
+* **DRY principle**: One implementation shared across all projects in the
+  ecosystem.
 
 
 How to Use
 ===============================================================================
 
-Create a ``manager.py`` file in your project root to integrate 
+Create a ``manager.py`` file in your project root to integrate
 the test commands:
 
 .. code-block:: python
@@ -75,7 +99,7 @@ the test commands:
 
 This setup provides two commands:
 
-* ``run-tests``: Execute test suites with unittest or pytest
+* ``run-tests``: Execute unittest-based test suites
 * ``run-coverage``: Generate code coverage reports
 
 Example usage:
@@ -83,7 +107,7 @@ Example usage:
 .. code-block:: bash
 
     python manager.py run-tests --test-type unit
-    python manager.py run-coverage --engine pytest
+    python manager.py run-coverage
 
 
 Available Commands
@@ -92,49 +116,56 @@ Available Commands
 run-tests
 -------------------------------------------------------------------------------
 
-Execute test suites with flexible options:
+Execute unittest-based test suites with flexible options:
 
 **Options:**
 
-* ``--engine``: Test engine to use (``unittest`` or ``pytest``). Default: ``unittest``
-* ``--test-type``: Folder name under ``./tests`` directory (e.g., ``unit``, ``integration``, ``functional``)
-* ``--pattern``: File pattern to match test files (e.g., ``*.py``, ``test_*.py``). Works with both engines.
+* ``--test-type``: Folder name under ``./tests`` directory (e.g., ``unit``,
+  ``integration``, ``functional``). Default: ``unit``
+* ``--pattern``: File pattern to match test files (e.g., ``*.py``,
+  ``test_*.py``). Defaults to multi-pattern discovery.
 
 **Examples:**
 
 .. code-block:: bash
 
-    # Run unit tests with unittest (default)
+    # Run unit tests (default)
     python manager.py run-tests --test-type unit
 
-    # Run integration tests with pytest
-    python manager.py run-tests --engine pytest --test-type integration
+    # Run integration tests
+    python manager.py run-tests --test-type integration
 
-    # Run tests with custom pattern
-    python manager.py run-tests --test-type functional --pattern "test_*.py"
+    # Run tests with a custom file pattern
+    python manager.py run-tests --test-type functional --pattern "*.py"
 
-    # Run all tests in a custom folder
+    # Run tests in a custom folder
     python manager.py run-tests --test-type "custom_folder"
 
 
 run-coverage
 -------------------------------------------------------------------------------
 
-Generate code coverage reports:
+Generate code coverage reports across all test directories:
 
 **Options:**
 
-* ``--engine``: Test engine to use (``unittest`` or ``pytest``). Default: ``unittest``
+* ``--save-report``: Save HTML, XML and data coverage reports to disk.
+  Default: ``True``
+* ``--fail-under``: Minimum total coverage percentage. Exits non-zero below it,
+  and takes precedence over the ``fail_under`` setting of the coverage
+  configuration. Default: unset, so the configured value applies.
 
 **Examples:**
 
 .. code-block:: bash
 
-    # Generate coverage with unittest
     python manager.py run-coverage
+    python manager.py run-coverage --save-report false
+    python manager.py run-coverage --fail-under 90
 
-    # Generate coverage with pytest
-    python manager.py run-coverage --engine pytest
+The HTML report lands in ``htmlcov/``, and a Cobertura ``coverage.xml`` beside
+it, with paths relative to the working directory so a CI platform can map them
+onto the repository.
 
 
 Quick Start
@@ -176,78 +207,32 @@ Tests and Coverage
 
     python manager.py run-tests --test-type unit
     python manager.py run-tests --test-type integration
-    python manager.py run-tests --test-type "another folder that contains test cases under ./tests"
     python manager.py run-tests --test-type functional --pattern "*.py"
+    python manager.py run-coverage
 
 
-Using PyTest
+Using pytest directly
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The `unittest` framework cannot discover or run pytest-style tests, it is designed to
-discover and run tests that are subclasses of `unittest.TestCase` and follow its
-conventions. Pytest-style tests (i.e., functions named test_* that are not inside a
-`unittest.TestCase` class, or tests using pytest fixtures, parametrize, etc.) are not
-recognized by unittest's discovery mechanism, `unittest` will simply ignore standalone
-test functions and any pytest-specific features...
-
-That's why you can use PyTest if required.
+``unittest`` cannot discover standalone ``test_*`` functions or use pytest
+fixtures. If your project relies on those features, invoke ``pytest`` directly:
 
 .. code-block:: bash
 
-    python manager.py run-tests --engine pytest
+    pytest tests/unit/
+    pytest -n auto --cov=your_package --cov-report=html
 
-..
-
-Test coverage
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Install ``pytest`` via ``pip`` or through ``core-dev-tools``:
 
 .. code-block:: bash
 
-    python manager.py run-coverage                          # For `unittest` framework...
-    python manager.py run-coverage --engine pytest          # For `PyTest`...
-    pytest -n auto --cov=core_tests --cov-report=html       # Direct `pytest` execution...
+    pip install pytest pytest-xdist pytest-cov
+    # or
+    pip install ".[dev]"  # if core-dev-tools includes pytest
 
 ..
 
 
-Best Practices
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When working with pytest, consider these optimization strategies:
-
-1. **Use parallel execution for independent tests:**
-
-   .. code-block:: bash
-
-       pytest -n auto
-
-   ..
-
-2. **Run fast unit tests first during development:**
-
-   .. code-block:: bash
-
-       pytest tests/unit/ -n auto
-
-   ..
-
-3. **Run functional tests with limited parallelism:**
-
-   .. code-block:: bash
-
-       pytest tests/functional/ -n 2  # Avoid AWS rate limits
-
-   ..
-
-4. **Use markers to run specific test subsets:**
-
-   .. code-block:: bash
-
-       pytest -m "unit and not slow" -n auto
-
-   ..
-
-
 Contributing
 ===============================================================================
 
@@ -256,7 +241,7 @@ Contributions are welcome! Please:
 1. Fork the repository
 2. Create a feature branch
 3. Write tests for new functionality
-4. Ensure all tests pass: ``pytest -n auto``
+4. Ensure all tests pass: ``python manager.py run-tests --test-type unit``
 5. Run linting: ``pylint core_tests``
 6. Run security checks: ``bandit -r core_tests``
 7. Submit a pull request
@@ -287,4 +272,4 @@ For questions or support, please open an issue on GitLab or contact the maintain
 Authors
 ===============================================================================
 
-* **Alejandro Cora González** - *Initial work* - alek.cora.glez@gmail.com
+* **Alejandro Cora González** - *Initial work* - alek.cora.glez@gmail.com

core_tests-2.2.0/core_tests/__init__.py

@@ -0,0 +1,21 @@
+"""
+Provides common elements for testing purposes.
+"""
+
+from importlib.metadata import PackageNotFoundError, version
+
+from core_tests.tests.base import BaseTestCase
+from core_tests.tests.runner import cli_tests
+
+try:
+    __version__ = version("core-tests")
+
+except PackageNotFoundError:
+    __version__ = "unknown"
+
+
+__all__ = [
+    "BaseTestCase",
+    "__version__",
+    "cli_tests",
+]

{core_tests-2.0.5 → core_tests-2.2.0}/core_tests/tests/base.py

@@ -1,5 +1,3 @@
-# -*- coding: utf-8 -*-
-
 """
 It's just the base class should be used for all
 test cases unittest-based within the code
@@ -7,7 +5,6 @@ ecosystem.
 """
 
 import os
-
 from unittest import TestCase