Skip to content

Parametrize shared Document tests over PurchaseInvoice and Receipt #40

Description

@TimEvci

Summary

PurchaseInvoice and Receipt are both thin subclasses of the same Document base, but their test files are independent copies with very different coverage: tests/test_purchase_invoice.py is 268 lines, tests/test_receipt.py is 51 lines and covers only five of the same test names (test_add_detail, test_delete, test_find_by_id, test_list_all, test_sync_endpoint). Everything only exercised in the purchase-invoice file — payments, detail updates/deletion with _destroy, attachments, register_payment, save round-trips — is untested for Receipt, even though the code paths are shared.

Details

Both classes differ only in _resource ("purchase_invoice" vs "receipt"), so the behavior under test is identical except for the URL segment and payload key. The current structure means:

  • New Document features get tested against one subclass only (whichever file the author copies into).
  • The two files drift — they already have.

Suggested fix

Parametrize the shared Document behavior over both subclasses:

@pytest.fixture(params=[PurchaseInvoice, Receipt])
def document_cls(request):
    return request.param
  • Move the shared tests into a single tests/test_document.py parametrized by document_cls, deriving expected paths from cls._resource instead of hard-coding purchase_invoices.
  • Keep (or add) only genuinely subclass-specific assertions in per-class files — likely just the endpoint/_resource values, which the parametrized suite covers anyway.

Result: Receipt inherits the full suite for free, total test code shrinks, and future Document subclasses get coverage by adding one fixture param.

Acceptance criteria

  • Every shared Document behavior test runs against both PurchaseInvoice and Receipt.
  • No duplicated test bodies between the two resource types.
  • Coverage for Receipt payments/details/attachments matches PurchaseInvoice.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions