macxred / pyledger

Python package to streamline the implementation and management of accounting systems.
MIT License
0 stars 0 forks source link

Drop `TestLedger` #8

Closed lasuk closed 2 days ago

lasuk commented 3 months ago

Description

TestLedger shall now inherit from MemoryLedger. It shall have a sole method: populate_mock_data() or load_sample_data() that loads mock accounting data of a fictional Swiss company from CSV files available in the PyLedger package.

Tasks:

  1. Change TestLedger to inherit from MemoryLedger. Drop unneeded methods.
  2. Save mock accounting data currently stored in TestLedger as CSV files in the PyLedger package instead of hard-coding the data in TestLedger.
  3. Implement populate_mock_data() or load_sample_data() that loads the mock accounting available in the PyLedger package. Use the LedgerEngine.restore() to load the data.
AlexTheWizardL commented 2 months ago

UPD: We need to drop TestLedger at all.

Motivation: Base test has mock data already integrated and together with MemoryLedger that is all we need.

AlexTheWizardL commented 2 days ago

Step 1: Deleting TestLedger and Updating test_standalone_ledger.py

  1. Drop Redundant Tests:

    • Remove test_standardize_ledger_columns and test_standardize_ledger_columns_ensure_date_type, as enforce_schema covers this functionality.
    • Remove test_add_ledger_entry since StandaloneLedger does not implement accessor or mutator methods.
  2. Retain Temporarily:

    • Keep test_tax_journal_entries and test_validate_account_balance until base tests are implemented, after which these will be removed.
    • Set up specific ACCOUNTS and TAX_CODES data to support remaining tests:

      ACCOUNTS = pd.concat([
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=1020),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=1030),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=1045),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=1170),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=2200),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=3000),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=6000, tax_code="InStd"),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=6100, tax_code="InStd"),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=6200, tax_code="InStd"),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=6300, tax_code="InStd"),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=6400, tax_code="InStd"),
       BaseTest.ACCOUNTS.query("account == 9992").assign(account=6500, tax_code="InStd"),
      ], ignore_index=True)
      
      TAX_CODES = pd.concat([
       BaseTest.TAX_CODES.query("id == 'Test'").assign(id="Exempt", account=None, rate=0),
       BaseTest.TAX_CODES.query("id == 'OutStdEx'").assign(account=2200),
       BaseTest.TAX_CODES.query("id == 'InStd'").assign(account=1170),
      ], ignore_index=True)
    • TODO: Consider defining test data using a CSV file instead of relying on BaseTest data. Using CSV offers clarity and reveals actual data content, making it more understandable and maintainable. This setup is temporary and will be removed at the end.
  3. Reassign Tests:

    • Move test_rounding_XY tests to assets base tests, as this logic belongs there.
  4. Final Clean-up:

    • Remove test_standalone_ledger.py entirely by the end of the project.

Step 2: Refactoring StandaloneLedger to Use Accessors Instead of Private Variables

  1. Drop All Class Variables Storing Data:

    • Remove any class variables in StandaloneLedger that are currently holding data. This will eliminate direct data dependencies within the class.
  2. Replace Variable Usage with Accessor Methods:

    • Identify all places in the code where these class variables were used.
    • Replace these instances with the appropriate accessor methods to ensure controlled access and consistency throughout the class.
  3. Architectural Consideration for StandaloneLedger:

    • Architect Alex is evaluating whether StandaloneLedger should remain in the class hierarchy, as its methods could potentially be integrated into LedgerEngine. He would like your perspective on the necessity of StandaloneLedger. If there are specific functionalities or conceptual distinctions that justify keeping it, highlighting those reasons will help clarify its role.