Test utility for validating OpenAPI documentation

Overview
Package version Code coverage Supported Python versions Supported Django versions Checked with mypy

DRF OpenAPI Tester

This is a test utility to validate DRF Test Responses against OpenAPI 2 and 3 schema. It has built-in support for:

  • OpenAPI 2/3 yaml or json schema files.
  • OpenAPI 2 schemas created with drf-yasg.
  • OpenAPI 3 schemas created with drf-spectacular.

Installation

pip install drf-openapi-tester

Usage

First instantiate one or more instances of SchemaTester:

from openapi_tester import SchemaTester

schema_tester = SchemaTester()

If you are using either drf-yasg or drf-spectacular this will be auto-detected, and the schema will be loaded by the SchemaTester automatically. If you are using schema files though, you will need to pass the file path to the tester:

from openapi_tester import SchemaTester

# path should be a string
schema_tester = SchemaTester(schema_file_path="./schemas/publishedSpecs.yaml")

Once you instantiate a tester, you can use it to test responses:

from openapi_tester.schema_tester import SchemaTester

# you need to create at least one instance of SchemaTester.
# you can pass kwargs to it
schema_tester = SchemaTester()


def test_response_documentation(client):
    response = client.get('api/v1/test/1')
    assert response.status_code == 200
    schema_tester.validate_response(response=response)

If you are using the Django testing framework, you can create a base APITestCase that incorporates schema validation:

from openapi_tester.schema_tester import SchemaTester
from rest_framework.test import APITestCase
from rest_framework.response import Response

schema_tester = SchemaTester()


class BaseAPITestCase(APITestCase):
    """ Base test class for api views including schema validation """

    @staticmethod
    def assertResponse(response: Response, **kwargs) -> None:
        """ helper to run validate_response and pass kwargs to it """
        schema_tester.validate_response(response=response, **kwargs)

Then use it in a test file:

from shared.testing import BaseAPITestCase


class MyAPITests(BaseAPITestCase):
    def test_some_view(self):
        response = self.client.get("...")
        self.assertResponse(response)

Options

You can pass options either globally, when instantiating a SchemaTester, or locally, when invoking validate_response:

from openapi_tester import SchemaTester, is_camel_case
from tests.utils import my_uuid_4_validator

schema_test_with_case_validation = SchemaTester(
    case_tester=is_camel_case,
    ignore_case=["IP"],
    validators=[my_uuid_4_validator]
)

Or

from openapi_tester import SchemaTester, is_camel_case
from tests.utils import my_uuid_4_validator

schema_tester = SchemaTester()


def my_test(client):
    response = client.get('api/v1/test/1')
    assert response.status_code == 200
    schema_tester.validate_response(
        response=response,
        case_tester=is_camel_case,
        ignore_case=["IP"],
        validators=[my_uuid_4_validator]
    )

case_tester

The case tester argument takes a callable that is used to validate the key casings of both schemas and responses. If nothing is passed, case validation is skipped.

The library currently has 4 built-in case testers:

  • is_pascal_case
  • is_snake_case
  • is_camel_case
  • is_kebab_case

You can of course pass your own custom case tester.

ignore_case

List of keys to ignore when testing key casing. This setting only applies when case_tester is not None.

validators

List of custom validators. A validator is a function that receives two parameters: schema_section and data, and returns either an error message or None, e.g.:

from typing import Any, Optional
from uuid import UUID


def my_uuid_4_validator(schema_section: dict, data: Any) -> Optional[str]:
    schema_format = schema_section.get("format")
    if schema_format == "uuid4":
        try:
            result = UUID(data, version=4)
            if not str(result) == str(data):
                return f"Expected uuid4, but received {data}"
        except ValueError:
            return f"Expected uuid4, but received {data}"
    return None

field_key_map

You can pass an optional dictionary that maps custom url parameter names into values, for cases where this cannot be inferred by the DRF EndpointEnumerator. A concrete use case for this option is when the django i18n locale prefixes.

from openapi_tester import SchemaTester

schema_tester = SchemaTester(field_key_map={
  "language": "en",
})

Schema Validation

When the SchemaTester loads a schema, it runs it through OpenAPI Spec validator which validates that the schema passes without specification compliance issues. In case of issues with the schema itself, the validator will raise the appropriate error.

Known Issues

  • We are using prance as a schema resolver, and it has some issues with the resolution of (very) complex OpenAPI 2.0 schemas. If you encounter issues, please document them here.

Contributing

Contributions are welcome. Please see the contributing guide

Comments
  • Add support for loading schema with oneOf, anyOf, allOf, not $refs

    Add support for loading schema with oneOf, anyOf, allOf, not $refs

    Hi fellas,

    I get this:

     File "/usr/local/lib/python3.8/site-packages/django_swagger_tester/testing.py", line 37, in validate_response
        verbose_error_message = format_response_tester_error(e, hint=e.response_hint)
      File "/usr/local/lib/python3.8/site-packages/django_swagger_tester/utils.py", line 47, in format_response_tester_error
        example_item = settings.loader_class.create_dict_from_schema(exception.schema)
      File "/usr/local/lib/python3.8/site-packages/django_swagger_tester/loaders.py", line 335, in create_dict_from_schema
        return self._iterate_schema_dict(schema)
      File "/usr/local/lib/python3.8/site-packages/django_swagger_tester/loaders.py", line 294, in _iterate_schema_dict
        elif read_type(value) == 'object':
      File "/usr/local/lib/python3.8/site-packages/django_swagger_tester/openapi.py", line 53, in read_type
        raise OpenAPISchemaError(
    django_swagger_tester.exceptions.OpenAPISchemaError: Schema item has an invalid `type` attribute. The type should be a single string.
    

    I then see this printed: Schema item: {'allOf': [{'type': 'object', 'description': 'Read-only Product Serializer', 'properties': {'slug': {'type': 'string', 'readOnly': True, 'pattern': '^[-a-zA-Z0-9_]+$'}, 'loop': {'type': 'string', 'readOnly': True}, 'sites': {'type': 'array', 'items': {'type': 'object', 'description': 'read-only Site serializer', 'properties': {'id': {'type': 'integer', 'readOnly': True}, 'slug': {'type': 'string', 'readOnly': True, 'pattern': '^[-a-zA-Z0-9_]+$'}, 'domain': {'type': 'string', 'readOnly': True}}, 'required': ['domain', 'id', 'slug']}, 'readOnly': True}, 'acr': {'allOf': [{'enum': ['3', '4'], 'type': 'string'}], 'readOnly': True}}, 'required': ['acr', 'loop', 'sites', 'slug']}], 'readOnly': True}

    which I prettified:

    {
      allOf: [
        {
          type: "object",
          description: "Read-only Product Serializer",
          properties: {
            slug: { type: "string", readOnly: True, pattern: "^[-a-zA-Z0-9_]+$" },
            loop: { type: "string", readOnly: True },
            sites: {
              type: "array",
              items: {
                type: "object",
                description: "read-only Site serializer",
                properties: {
                  id: { type: "integer", readOnly: True },
                  slug: {
                    type: "string",
                    readOnly: True,
                    pattern: "^[-a-zA-Z0-9_]+$",
                  },
                  domain: { type: "string", readOnly: True },
                },
                required: ["domain", "id", "slug"],
              },
              readOnly: True,
            },
            acr: { allOf: [{ enum: ["3", "4"], type: "string" }], readOnly: True },
          },
          required: ["acr", "loop", "sites", "slug"],
        },
      ],
      readOnly: True,
    };
    

    I dont see any issue with the type key here.

    bug 
    opened by Goldziher 23
  • Middleware

    Middleware

    Another approach to test is having Django middleware check the requests and responses across the wire.

    Two projects do that https://github.com/zlqm/openapi-toolset and https://github.com/Cohey0727/drf_open_api_validator . I am using the former, with good results (and few more patches pending), as the latter seems stagnant at https://github.com/Cohey0727/drf_open_api_validator/issues/3 .

    While I am moderately happy with my current solution, django-swagger-tester looks like a more comprehensive framework and it could benefit from such a 'live' testing mode, which could be engaged during unit tests, or on real sites.

    opened by jayvdb 16
  • validate_response() fails when 'pk' path parameter coerced by DRF

    validate_response() fails when 'pk' path parameter coerced by DRF

    By default, DRF seems to change pk path parameters to the actual primary key field name for the schema. This leads to a strange error when the SchemaTester:

    >>> response = client.get("/api/names/123/")
    >>> schema_tester.validate_response(response)
    openapi_tester.exceptions.UndocumentedSchemaSectionError: Error: Unsuccessfully tried to index the OpenAPI schema by `/api/names/{pk}/`. 
    
    For debugging purposes, other valid routes include: 
    
        • /api/names/
        • /api/names/{id}/
        • ...
    

    When I set REST_FRAMEWORK["SCHEMA_COERCE_PATH_PK"] = False in my settings, it works, but then the schema uses the path parameter {pk} instead of {id}, which is not very nice.

    My Name model's primary key field name is id, and my ViewSet generating the routes looks like this:

    class NameViewSet(viewsets.ReadOnlyModelViewSet):
        queryset = models.Name.objects.all()
        serializer_class = serializers.NameSerializer
    
    router = SimpleRouter()
    router.register(r"names", NameViewSet)
    

    (Also possible that I've configured something incorrectly, since a lot has changed in the package recently...)

    bug 
    opened by saeub 15
  • Nullable enums not validating

    Nullable enums not validating

    Hi, I'm having the following issue. drf-spectacular for some reason generates nullable enums like a oneOf of two enum types, one which contains the enum options and a NullEnum containing only the None option. So for example, if I have the following field in my model:

        building_type = models.CharField(
            max_length=25,
            choices=(('hs', 'House'), ('apt', 'Apartment'), ('farm', 'Farm')),
            default=None,
            null=True,
        )
    

    It will generate the following field in my schema:

    ...
            building_type:
              nullable: true
              oneOf:
              - $ref: '#/components/schemas/BuildingTypeEnum'
              - $ref: '#/components/schemas/NullEnum'
    ...
        BuildingTypeEnum:
          enum:
          - hs
          - apt
          - farm
          type: string
        NullEnum:
            enum:
            - null
    

    So the issue I'm having is that drf-openapi-tester fails to validate this when using a valid enum option (e.g. hs in the example). This is because handle_one_of method will fail if the value matches both of the types. It's matching the BuildingTypeEnum correctly because hs is one of the options in the enum, but it's also matching the NullEnum because of these two lines in test_schema_section:

            schema_section_type = self.get_schema_type(schema_section)
            if not schema_section_type:
                return
    

    Since NullEnum doesn't have a type or a properties field, get_schema_type is returning None and so it will exit early without running the validators.

    The quickest fix I can think of to support this case is to change those two lines to:

            schema_section_type = self.get_schema_type(schema_section)
            if not schema_section_type and 'enum' not in schema_section:
                return
    

    but maybe theres' some more generic fix?

    FTR, this is what drf-spectacular says about this NullEnum type: https://github.com/tfranzel/drf-spectacular/issues/235

    opened by idesoto-rover 13
  • Package has hard dependency on djangorestframework_camel_case

    Package has hard dependency on djangorestframework_camel_case

    Hi @sondrelg ,

    So the package currently has a hard dependency on djangorestframework_camel_case, as you can see in the below stacktrace. I do not use this package though, and I don't think this should be a requirement really. You can use "inflection" for this purpose, or use your own regex based solution instead.

    Traceback (most recent call last):
      File "manage.py", line 16, in <module>
        execute_from_command_line(sys.argv)
      File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
        utility.execute()
      File "/usr/local/lib/python3.8/site-packages/django/core/management/__init__.py", line 395, in execute
        self.fetch_command(subcommand).run_from_argv(self.argv)
      File "/usr/local/lib/python3.8/site-packages/django/core/management/base.py", line 343, in run_from_argv
        connections.close_all()
      File "/usr/local/lib/python3.8/site-packages/django/db/utils.py", line 232, in close_all
        for alias in self:
      File "/usr/local/lib/python3.8/site-packages/django/db/utils.py", line 226, in __iter__
        return iter(self.databases)
      File "/usr/local/lib/python3.8/site-packages/django/utils/functional.py", line 48, in __get__
        res = instance.__dict__[self.name] = self.func(instance)
      File "/usr/local/lib/python3.8/site-packages/django/db/utils.py", line 153, in databases
        self._databases = settings.DATABASES
      File "/usr/local/lib/python3.8/site-packages/django/conf/__init__.py", line 83, in __getattr__
        self._setup(name)
      File "/usr/local/lib/python3.8/site-packages/django/conf/__init__.py", line 70, in _setup
        self._wrapped = Settings(settings_module)
      File "/usr/local/lib/python3.8/site-packages/django/conf/__init__.py", line 177, in __init__
        mod = importlib.import_module(self.SETTINGS_MODULE)
      File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module
        return _bootstrap._gcd_import(name[level:], package, level)
      File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
      File "<frozen importlib._bootstrap>", line 991, in _find_and_load
      File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
      File "<frozen importlib._bootstrap_external>", line 783, in exec_module
      File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
      File "/app/consumer_portal/settings.py", line 17, in <module>
        from django_swagger_tester.loaders import DrfSpectacularSchemaLoader
      File "/usr/local/lib/python3.8/site-packages/django_swagger_tester/loaders.py", line 12, in <module>
        from django_swagger_tester.utils import Route
      File "/usr/local/lib/python3.8/site-packages/django_swagger_tester/utils.py", line 12, in <module>
        from djangorestframework_camel_case.util import camelize_re, underscore_to_camel
    ModuleNotFoundError: No module named 'djangorestframework_camel_case'
    
    opened by Goldziher 12
  • Integration for drf-spectacular

    Integration for drf-spectacular

    drf-yasg project is dead But now a new project https://github.com/tfranzel/drf-spectacular with support for the openapi scheme is actively developing. Is integration with this project possible?

    enhancement 
    opened by MissiaL 11
  • #245 fix validation for additionalProperties

    #245 fix validation for additionalProperties

    Fixes issues described in #245:

    • allows specifying a schema in additionalProperties and validates any extra keys in the response that are not defined in the properties section against this schema
    • additionalProperties can be an empty schema {} and this means any values are allowed in extra keys
    • additionalProperties can be True and this behaves the same as an empty schema (this was already working)
    opened by idesoto-rover 10
  • regex to support alt application/*json types

    regex to support alt application/*json types

    In relation to this issue - where schema tester was failing with an UndocumentedSchemaSectionError on our OAS defintitions that had application/vnd.api+json content types.

    opened by darduf 9
  • Deprecations and package renaming

    Deprecations and package renaming

    Deletions

    • Middleware
    • APIViews
    • All caching log, hashing logic, and migrations
    • All tests for the above logic
    • Related docs

    Renaming

    • Renames the package from django-swagger-tester to django-openapi-tester
    • Renames the source directory from django_swagger_tester to openapi_tester
    • Renames the package settings from SWAGGER_TESTER to OPENAPI_TESTER
    opened by sondrelg 8
  • Add drf spectacular support

    Add drf spectacular support

    This PR adds support for DRF spectacular (see issue #61 ).

    I didn't test this locally, and haven't seen any tests written for drf-yasg so I didn't write tests for this code. As such this PR is currently WIP, and I will try to find time to complete it in the near future. If someone else would like to test it or add tests that will be awesome.

    Changes:

    1. Added support for drf spectacular following the example of drf-yasg
    2. Resolved issues reported by pytest (wrong version in assert + deprecated import statement)
    opened by Goldziher 8
  • openapi version

    openapi version

    Hi

    I have an openapi yaml of version 3.0.1. When I run SchemaTester I get the following failure.

      File "/../venv/lib/python3.9/site-packages/openapi_spec_validator/validation/validators.py", line 75, in validate
        raise err
    openapi_spec_validator.validation.exceptions.OpenAPIValidationError: '3.0.1' does not match '^3\\.1\\.\\d+(-.+)?$'
    
    Failed validating 'pattern' in schema['properties']['openapi']:
        {'pattern': '^3\\.1\\.\\d+(-.+)?$', 'type': 'string'}
    
    On instance['openapi']:
        '3.0.1' 
    

    The validator doesn't seem to be picking up that this openapi is of version 3.0.#. Looking through traceback, it appears that openapi_v31_spec_validator is the set/default validator. Is it possible to override/address this so it uses openapi_v30_schema_validator

    opened by darduf 7
  • requestBody schema testing

    requestBody schema testing

    We noticed in our OAS testing that the requestBody schema is not tested. For example if the post.requestBody is removed from a path (that expects a requestBody) in the OAS, there is no schema checking here and tests pass. Similarly if the requestBody is incorrect, the tests also still pass.

    Is there scope to include such a test in this package?

    Thanks!

    opened by darduf 3
  • Trailing slash in parametrized path

    Trailing slash in parametrized path

    This branch is based on https://github.com/snok/drf-openapi-tester/pull/284 that has the required drf setup to show where this is failing.

    I have removed the trailing slash on paths in /drf-openapi-tester/tests/schemas/sample-schemas/content_types.yaml to represent our OAS defined paths.

    This reproduces the error we are seeing, where the Undocumented route parametrized path has a trailing slash:

    schema = {'/api/pet': {'post': {'description': 'Add a new pet to the store', 'operationId': 'addPet', 'requestBody': {'content'..., 'name': 'status', 'schema': {'type': 'string'}}], 'responses': {'405': {'description': 'Invalid input'}}, ...}}, ...}
    key = '/api/pet/{petId}/'
    error_addon = '\n\nUndocumented route /api/pet/{petId}/.\n\nDocumented routes: /api/pet\n\t• /api/pet/findByStatus\n\t• /api/pet/fin...rId}\n\t• /api/user\n\t• /api/user/createWithList\n\t• /api/user/login\n\t• /api/user/logout\n\t• /api/user/{username}'
    
        @staticmethod
        def get_key_value(schema: dict[str, dict], key: str, error_addon: str = "") -> dict:
            """
            Returns the value of a given key
            """
            try:
                return schema[key]
            except KeyError as e:
    >           raise UndocumentedSchemaSectionError(
                    UNDOCUMENTED_SCHEMA_SECTION_ERROR.format(key=key, error_addon=error_addon)
                ) from e
    E           openapi_tester.exceptions.UndocumentedSchemaSectionError: Error: Unsuccessfully tried to index the OpenAPI schema by `/api/pet/{petId}/`. 
    E           
    E           Undocumented route /api/pet/{petId}/.
    E           
    E           Documented routes: /api/pet
    E               • /api/pet/findByStatus
    E               • /api/pet/findByTags
    E               • /api/pet/{petId}
    E               • /api/pet/{petId}/uploadImage
    E               • /api/store/inventory
    E               • /api/store/order
    E               • /api/store/order/{orderId}
    E               • /api/user
    E               • /api/user/createWithList
    E               • /api/user/login
    E               • /api/user/logout
    E               • /api/user/{username}
    
    openapi_tester/schema_tester.py:99: UndocumentedSchemaSectionError
    

    Removing + "/" from this line of code solves the issue for us, and is part of the discussion from this issue:

    File: third_party/drf-openapi-tester/openapi_tester/loaders.py
    146:         parsed_path = url_object.path if url_object.path.endswith("/") else url_object.path + "/"
    
    
    opened by darduf 1
  • example of failing test on related_field

    example of failing test on related_field

    In relation to this issue - where schema tester was failing with an UndocumentedSchemaSectionError on our OAS definitions that uses DRF JSON:API RelationshipView

    We would expect the schema tester to successfully index /api/pet/{petId}/relationships/owner/

    FAILED tests/test_django_framework.py::PetsAPITests::test_create_pet_owner_relationship - openapi_tester.exceptions.UndocumentedSchemaSectionError: Error: Unsuccessfully tried to index the OpenAPI schema by `/api/pet/{petId}/relationships/{relatedField}/`. 
    
    Undocumented route /api/pet/{petId}/relationships/{relatedField}/.
    
    Documented routes: /api/pet/
    	• /api/pet/findByStatus/
    	• /api/pet/findByTags/
    	• /api/pet/{petId}/
    	• /api/pet/{petId}/relationships/owner/
    	• /api/pet/{petId}/uploadImage/
    	• /api/store/inventory/
    	• /api/store/order/
    	• /api/store/order/{orderId}/
    	• /api/user/
    	• /api/user/createWithList/
    	• /api/user/login/
    	• /api/user/logout/
    	• /api/user/{username}/
    

    739a3b16459378d9a9aeba3a111702fa95f5f72f replicates the issue we are seeing

    opened by darduf 0
  • related_field not recognised in URL path

    related_field not recognised in URL path

    We are using RelationshipView from the DRF JSON:API package, and are experiencing limitations when using the schema tester on these type of endpoints.

    We have the following path/view that handles the application of team members (POST/DELETE)

        re_path(
            r"^team/(?P<pk>\d+)/relationships/(?P<related_field>[-\w]+)/?$",
            views.TeamMembersRelationshipView.as_view(),
            name="team-members-relation",
        ),
    

    When SchemaTester(schema_file_path=path/to/schemae/file.yaml) hits this path

            response = self.client.delete(
                reverse(
                    "teams:team-members-relation",
                    kwargs={
                        "pk": self.team_001.pk,
                        "related_field": "members",
                    },
                ),
                payload,
                content_type="application/vnd.api+json",
            )
            self.assertResponse(response)
    

    We receive an UndocumentedSchemaSectionError

    Traceback (most recent call last):
      File "../.venv/lib/python3.9/site-packages/openapi_tester/schema_tester.py", line 102, in get_key_value
        return schema[key]
    KeyError: '/api/team/{id}/relationships/{related_field}'
    
    The above exception was the direct cause of the following exception:
    
    Traceback (most recent call last):
      File "../.venv/lib/python3.9/site-packages/openapi_tester/schema_tester.py", line 403, in validate_response
        response_schema = self.get_response_schema_section(response)
      File "../.venv/lib/python3.9/site-packages/openapi_tester/schema_tester.py", line 144, in get_response_schema_section
        route_object = self.get_key_value(
      File "../.venv/lib/python3.9/site-packages/openapi_tester/schema_tester.py", line 104, in get_key_value
        raise UndocumentedSchemaSectionError(
    openapi_tester.exceptions.UndocumentedSchemaSectionError: Error: Unsuccessfully tried to index the OpenAPI schema by `/api/team/{id}/relationships/{related_field}`. 
    
    Undocumented route /api/team/{id}/relationships/{related_field}.
    
    Documented routes:
            • ...
            • /api/teams
            • /api/team/{id}
            • /api/team/{id}/relationships/members
    

    Why isn't the (undocumented) path resolving /api/team/{id}/relationships/{related_field} to the (documented) desired path /api/team/{id}/relationships/members as expected? Is there something additional that needs to be defined in order for the schema tester to recognise these related_field path keys?

    opened by darduf 7
Releases(v2.3.1)
  • v2.3.1(Dec 2, 2022)

    What's Changed

    Properly includes vnd.api+json content type fix by @darduf in https://github.com/snok/drf-openapi-tester/pull/292

    Full Changelog: https://github.com/snok/drf-openapi-tester/compare/v2.3.0...v2.3.1

    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Dec 1, 2022)

    What's Changed

    • Officially support Python 3.11/Django 4.1 by @sondrelg in https://github.com/snok/drf-openapi-tester/pull/289
    • Add support for application/*json types by @darduf in https://github.com/snok/drf-openapi-tester/pull/284
    • Fix trailing slash issue by @darduf @sondrelg in https://github.com/snok/drf-openapi-tester/pull/290

    Full Changelog: https://github.com/snok/drf-openapi-tester/compare/v2.2.0...v2.3.0

    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Nov 5, 2022)

    What's Changed

    • feat: adding url schema loader functionality by @maticardenas in https://github.com/snok/drf-openapi-tester/pull/283

    New Contributors

    • @maticardenas made their first contribution in https://github.com/snok/drf-openapi-tester/pull/283

    Full Changelog: https://github.com/snok/drf-openapi-tester/compare/v2.1.3...v2.2.0

    Source code(tar.gz)
    Source code(zip)
  • v2.1.3(Oct 7, 2022)

    What's Changed

    • Unpin djangorestframework version by @sondrelg in https://github.com/snok/drf-openapi-tester/pull/279

    Full Changelog: https://github.com/snok/drf-openapi-tester/compare/v2.1.2...v2.1.3

    Source code(tar.gz)
    Source code(zip)
  • v2.1.2(Sep 25, 2022)

    What's Changed

    • Fix broken OpenAPI parsing for OpenAPI v3.0 schemas by @darduf in https://github.com/snok/drf-openapi-tester/pull/274
    • Pin DRF to <3.14 until upstream issue is fixed in drf-yasg by @sondrelg in https://github.com/snok/drf-openapi-tester/pull/268

    New Contributors

    • @darduf made their first contribution in https://github.com/snok/drf-openapi-tester/pull/274

    Full Changelog: https://github.com/snok/drf-openapi-tester/compare/v2.1.1...v2.1.2

    Source code(tar.gz)
    Source code(zip)
  • v2.1.1(Jun 28, 2022)

  • v2.1.0(Apr 19, 2022)

  • v2.0.1(Apr 10, 2022)

  • v2.0.0(Dec 29, 2021)

    Breaking changes

    • Removes Internal library properties from the module's __init__.py. Don't expect this to impact anyone, but is a breaking change.
    • Drops Django 2.2 support officially (but might still work)
    • Drops Python 3.6 support officially (but might still work)

    We currently support Django 3.0 - 4.0, and Python 3.7 - 3.10.

    Improvements

    • Adopted flake8-type-checking and cleaned up imports considerably (https://github.com/snok/drf-openapi-tester/pull/251)
    Source code(tar.gz)
    Source code(zip)
  • v1.3.11(Dec 18, 2021)

  • v1.3.10(Nov 9, 2021)

    Fixes an issue where allowed additional-properties were raising KeyErrors (https://github.com/snok/drf-openapi-tester/pull/239). Thanks @alexpaulzor 👏

    Source code(tar.gz)
    Source code(zip)
  • v1.3.9(Nov 2, 2021)

  • v1.3.8(Oct 31, 2021)

  • v1.3.7(May 20, 2021)

  • v1.3.6(May 20, 2021)

  • v1.3.5(Feb 28, 2021)

  • v1.3.4(Feb 27, 2021)

  • v1.3.3(Feb 25, 2021)

    • Removes a 3.8 functools feature that accidentally broke the package on earlier Python versions. Replaced it with a built-in Django equivalent (#222)
    Source code(tar.gz)
    Source code(zip)
  • v1.3.2(Feb 21, 2021)

  • v1.3.1(Feb 21, 2021)

  • v1.3.0(Feb 20, 2021)

    1. Added validators for the "format" keyword, handling the following format values generated by DRF and DRF derived libraries: "uuid", "base64", "email", "uri", "url", "ipv4", "ipv6" and "time" validator
    2. Added support for dynamic url parameters (DRF feature) in schemas
    3. Added an option to pass a map of custom url parameters and values
    4. Fixed handling of byte format to test for base64 string instead of bytes Refactored error messages to be more concise and precise
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Feb 14, 2021)

  • v1.1.0(Feb 12, 2021)

  • v1.0.0(Feb 11, 2021)

    • Initial release
    • Has full validation for OpenAPI types, formats, and other OAS features
    • Supports anyOf, oneOf, allOf reference handling explicitly and the not keyword implicitly
    • Includes additional case checking for schema and response keys
    Source code(tar.gz)
    Source code(zip)
Coverage plugin for pytest.

Overview docs tests package This plugin produces coverage reports. Compared to just using coverage run this plugin does some extras: Subprocess suppor

pytest-dev 1.4k Dec 29, 2022
a socket mock framework - for all kinds of socket animals, web-clients included

mocket /mɔˈkɛt/ A socket mock framework for all kinds of socket animals, web-clients included - with gevent/asyncio/SSL support ...and then MicroPytho

Giorgio Salluzzo 249 Dec 14, 2022
Mypy static type checker plugin for Pytest

pytest-mypy Mypy static type checker plugin for pytest Features Runs the mypy static type checker on your source files as part of your pytest test run

Dan Bader 218 Jan 03, 2023
It's a simple script to generate a mush on code forces, the script will accept the public problem urls only or polygon problems.

Codeforces-Sheet-Generator It's a simple script to generate a mushup on code forces, the script will accept the public problem urls only or polygon pr

Ahmed Hossam 10 Aug 02, 2022
Travel through time in your tests.

time-machine Travel through time in your tests. A quick example: import datetime as dt

Adam Johnson 373 Dec 27, 2022
A framework-agnostic library for testing ASGI web applications

async-asgi-testclient Async ASGI TestClient is a library for testing web applications that implements ASGI specification (version 2 and 3). The motiva

122 Nov 22, 2022
Automated Security Testing For REST API's

Astra REST API penetration testing is complex due to continuous changes in existing APIs and newly added APIs. Astra can be used by security engineers

Flipkart Incubator 2.1k Dec 31, 2022
Generate random test credit card numbers for testing, validation and/or verification purposes.

Generate random test credit card numbers for testing, validation and/or verification purposes.

Dark Hunter 141 5 Nov 14, 2022
pywinauto is a set of python modules to automate the Microsoft Windows GUI

pywinauto is a set of python modules to automate the Microsoft Windows GUI. At its simplest it allows you to send mouse and keyboard actions to windows dialogs and controls, but it has support for mo

3.8k Jan 06, 2023
Pyramid debug toolbar

pyramid_debugtoolbar pyramid_debugtoolbar provides a debug toolbar useful while you're developing your Pyramid application. Note that pyramid_debugtoo

Pylons Project 95 Sep 17, 2022
🐍 Material for PyData Global 2021 Presentation: Effective Testing for Machine Learning Projects

Effective Testing for Machine Learning Projects Code for PyData Global 2021 Presentation by @edublancas. Slides available here. The project is develop

Eduardo Blancas 73 Nov 06, 2022
Fully functioning price detector built with selenium and python

Fully functioning price detector built with selenium and python

mark sikaundi 4 Mar 30, 2022
A mocking library for requests

httmock A mocking library for requests for Python 2.7 and 3.4+. Installation pip install httmock Or, if you are a Gentoo user: emerge dev-python/httm

Patryk Zawadzki 452 Dec 28, 2022
Free cleverbot without headless browser

Cleverbot Scraper Simple free cleverbot library that doesn't require running a heavy ram wasting headless web browser to actually chat with the bot, a

Matheus Fillipe 3 Sep 25, 2022
WomboAI Art Generator

WomboAI Art Generator Automate AI art generation using wombot.art. Also integrated into SnailBot for you to try out. Setup Install Python Go to the py

nbee 7 Dec 03, 2022
Let your Python tests travel through time

FreezeGun: Let your Python tests travel through time FreezeGun is a library that allows your Python tests to travel through time by mocking the dateti

Steve Pulec 3.5k Dec 29, 2022
The async ready version of the AniManga library created by centipede000.

Async-Animanga An Async/Aiohttp compatible library. Async-Animanga is an async ready web scraping library that returns Manga information from animepla

3 Sep 22, 2022
automate the procedure of 403 response code bypass

403bypasser automate the procedure of 403 response code bypass Description i notice a lot of #bugbountytips describe how to bypass 403 response code s

smackerdodi2 40 Dec 16, 2022
Akulaku Create NewProduct Automation using Selenium Python

Akulaku-Create-NewProduct-Automation Akulaku Create NewProduct Automation using Selenium Python Usage: 1. Install Python 3.9 2. Open CMD on Bot Folde

Rahul Joshua Damanik 1 Nov 22, 2021
Mockoon is the easiest and quickest way to run mock APIs locally. No remote deployment, no account required, open source.

Mockoon Mockoon is the easiest and quickest way to run mock APIs locally. No remote deployment, no account required, open source. It has been built wi

mockoon 4.4k Dec 30, 2022