Building a Comprehensive Accounting System Integration Test – Day 5

by Joche Ojeda | May 5, 2025 | Uncategorized

Integration testing is a critical phase in software development where individual modules are combined and tested as a group. In our accounting system, we’ve created a robust integration test that demonstrates how the Document module and Chart of Accounts module interact to form a functional accounting system. In this post, I’ll explain the components and workflow of our integration test.

The Architecture of Our Integration Test

Our integration test simulates a small retail business’s accounting operations. Let’s break down the key components:

Test Fixture Setup

The AccountingIntegrationTests class contains all our test methods and is decorated with the [TestFixture] attribute to identify it as a NUnit test fixture. The Setup method initializes our services and data structures:

[SetUp]
public async Task Setup()
{
    // Initialize services
    _auditService = new AuditService();
    _documentService = new DocumentService(_auditService);
    _transactionService = new TransactionService();
    _accountValidator = new AccountValidator();
    _accountBalanceCalculator = new AccountBalanceCalculator();
    
    // Initialize storage
    _accounts = new Dictionary<string, AccountDto>();
    _documents = new Dictionary<string, IDocument>();
    _transactions = new Dictionary<string, ITransaction>();
    
    // Create Chart of Accounts
    await SetupChartOfAccounts();
}

This method:

1. Creates instances of our services
2. Sets up in-memory storage for our entities
3. Calls SetupChartOfAccounts() to create our initial chart of accounts

Chart of Accounts Setup

The SetupChartOfAccounts method creates a basic chart of accounts for our retail business:

private async Task SetupChartOfAccounts()
{
    // Clear accounts dictionary in case this method is called multiple times
    _accounts.Clear();
    
    // Assets (1xxxx)
    await CreateAccount("Cash", "10100", AccountType.Asset, "Cash on hand and in banks");
    await CreateAccount("Accounts Receivable", "11000", AccountType.Asset, "Amounts owed by customers");
    // ... more accounts
    
    // Verify all accounts are valid
    foreach (var account in _accounts.Values)
    {
        bool isValid = _accountValidator.ValidateAccount(account);
        Assert.That(isValid, Is.True, $"Account {account.AccountName} validation failed");
    }
    
    // Verify expected number of accounts
    Assert.That(_accounts.Count, Is.EqualTo(17), "Expected 17 accounts in chart of accounts");
}

This method:

1. Creates accounts for each category (Assets, Liabilities, Equity, Revenue, and Expenses)
2. Validates each account using our AccountValidator
3. Ensures we have the expected number of accounts

Individual Transaction Tests

We have separate test methods for specific transaction types:

Purchase of Inventory

CanRecordPurchaseOfInventory demonstrates recording a supplier invoice:

[Test]
public async Task CanRecordPurchaseOfInventory()
{
    // Arrange - Create document
    var document = new DocumentDto { /* properties */ };
    
    // Act - Create document, transaction, and entries
    var createdDocument = await _documentService.CreateDocumentAsync(document, TEST_USER);
    // ... create transaction and entries
    
    // Validate transaction
    var isValid = await _transactionService.ValidateTransactionAsync(
        createdTransaction.Id, ledgerEntries);
        
    // Assert
    Assert.That(isValid, Is.True, "Transaction should be balanced");
}

This test:

1. Creates a document for our inventory purchase
2. Creates a transaction linked to that document
3. Creates ledger entries (debiting Inventory, crediting Accounts Payable)
4. Validates that the transaction is balanced (debits = credits)

Sale to Customer

CanRecordSaleToCustomer demonstrates recording a customer sale:

[Test]
public async Task CanRecordSaleToCustomer()
{
    // Similar pattern to inventory purchase, but with sale-specific entries
    // ...
    
    // Create ledger entries - a more complex transaction with multiple entries
    var ledgerEntries = new List<ILedgerEntry>
    {
        // Cash received
        // Sales revenue
        // Cost of goods sold
        // Reduce inventory
    };
    
    // Validate transaction
    // ...
}

This test is more complex, recording both the revenue side (debit Cash, credit Sales Revenue) and the cost side (debit Cost of Goods Sold, credit Inventory) of a sale.

Full Accounting Cycle Test

The CanExecuteFullAccountingCycle method ties everything together:

[Test]
public async Task CanExecuteFullAccountingCycle()
{
    // Run these in a defined order, with clean account setup first
    _accounts.Clear();
    _documents.Clear();
    _transactions.Clear();
    
    await SetupChartOfAccounts();
    
    // 1. Record inventory purchase
    await RecordPurchaseOfInventory();
    
    // 2. Record sale to customer
    await RecordSaleToCustomer();
    
    // 3. Record utility expense
    await RecordBusinessExpense();
    
    // 4. Create a payment to supplier
    await RecordPaymentToSupplier();
    
    // 5. Verify account balances
    await VerifyAccountBalances();
}

This test:

1. Starts with a clean state
2. Records a sequence of business operations
3. Verifies the final account balances

Mock Account Balance Calculator

The MockAccountBalanceCalculator is a crucial part of our test that simulates how a real database would work:

public class MockAccountBalanceCalculator : AccountBalanceCalculator
{
    private readonly Dictionary<string, AccountDto> _accounts;
    private readonly Dictionary<Guid, List<LedgerEntryDto>> _ledgerEntriesByTransaction = new();
    private readonly Dictionary<Guid, decimal> _accountBalances = new();

    public MockAccountBalanceCalculator(
        Dictionary<string, AccountDto> accounts,
        Dictionary<string, ITransaction> transactions)
    {
        _accounts = accounts;
        
        // Create mock ledger entries for each transaction
        InitializeLedgerEntries(transactions);
        
        // Calculate account balances based on ledger entries
        CalculateAllBalances();
    }

    // Methods to initialize and calculate
    // ...
}

This class:

1. Takes our accounts and transactions as inputs
2. Creates a collection of ledger entries for each transaction
3. Calculates account balances based on these entries
4. Provides methods to query account balances and ledger entries

The InitializeLedgerEntries method creates a collection of ledger entries for each transaction:

private void InitializeLedgerEntries(Dictionary<string, ITransaction> transactions)
{
    // For inventory purchase
    if (transactions.TryGetValue("InventoryPurchase", out var inventoryPurchase))
    {
        var entries = new List<LedgerEntryDto>
        {
            // Create entries for this transaction
            // ...
        };
        _ledgerEntriesByTransaction[inventoryPurchase.Id] = entries;
    }
    
    // For other transactions
    // ...
}

The CalculateAllBalances method processes these entries to calculate account balances:

private void CalculateAllBalances()
{
    // Initialize all account balances to zero
    foreach (var account in _accounts.Values)
    {
        _accountBalances[account.Id] = 0m;
    }
    
    // Process each transaction's ledger entries
    foreach (var entries in _ledgerEntriesByTransaction.Values)
    {
        foreach (var entry in entries)
        {
            if (entry.EntryType == EntryType.Debit)
            {
                _accountBalances[entry.AccountId] += entry.Amount;
            }
            else // Credit
            {
                _accountBalances[entry.AccountId] -= entry.Amount;
            }
        }
    }
}

This approach closely mirrors how a real accounting system would work with a database:

1. Ledger entries are stored in collections (similar to database tables)
2. Account balances are calculated by processing all relevant entries
3. The calculator provides methods to query this data (similar to a repository)

Balance Verification

The VerifyAccountBalances method uses our mock calculator to verify account balances:

private async Task VerifyAccountBalances()
{
    // Create mock balance calculator
    var mockBalanceCalculator = new MockAccountBalanceCalculator(_accounts, _transactions);
    
    // Verify individual account balances
    decimal cashBalance = mockBalanceCalculator.CalculateAccountBalance(
        _accounts["Cash"].Id, 
        _testDate.AddDays(15)
    );
    Assert.That(cashBalance, Is.EqualTo(-2750m), "Cash balance is incorrect");
    
    // ... verify other account balances
    
    // Also verify the accounting equation
    // ...
}

The Benefits of Our Collection-Based Approach

Our redesigned MockAccountBalanceCalculator offers several advantages:

1. Data-Driven: All calculations are based on collections of data, not hardcoded values.
2. Flexible: New transactions can be added easily without changing calculation logic.
3. Maintainable: If transaction amounts change, we only need to update them in one place.
4. Realistic: This approach closely mirrors how a real database-backed accounting system would work.
5. Extensible: We can add support for more complex queries like filtering by date range.

The Goals of Our Integration Test

Our integration test serves several important purposes:

1. Verify Module Integration: Ensures that the Document module and Chart of Accounts module work correctly together.
2. Validate Business Workflows: Confirms that standard accounting workflows (purchasing, sales, expenses, payments) function as expected.
3. Ensure Data Integrity: Verifies that all transactions maintain balance (debits = credits) and that account balances are accurate.
4. Test Double-Entry Accounting: Confirms that our system properly implements double-entry accounting principles where every transaction affects at least two accounts.
5. Validate Accounting Equation: Ensures that the fundamental accounting equation (Assets = Liabilities + Equity + (Revenues – Expenses)) remains balanced.

Conclusion

This integration test demonstrates the core functionality of our accounting system using a data-driven approach that closely mimics a real database. By simulating a retail business’s transactions and storing them in collections, we’ve created a realistic test environment for our double-entry accounting system.

The collection-based approach in our MockAccountBalanceCalculator allows us to test complex accounting logic without an actual database, while still ensuring that our calculations are accurate and our accounting principles are sound.

While this test uses in-memory collections rather than a database, it provides a strong foundation for testing the business logic of our accounting system in a way that would translate easily to a real-world implementation.

Repo

egarim/SivarErp: Open Source ERP

About Us

YouTube

https://www.youtube.com/c/JocheOjedaXAFXAMARINC

Our sites

• https://www.bitframeworks.com
• https://www.xari.io
• https://www.xafers.training

Let’s discuss your XAF

This call/zoom will give you the opportunity to define the roadblocks in your current XAF solution. We can talk about performance, deployment or custom implementations. Together we will review you pain points and leave you with recommendations to get your app back in track

https://calendly.com/bitframeworks/bitframeworks-free-xaf-support-hour

Our free A.I courses on Udemy

• • Introduction to Microsoft A.I Extensions
    https://www.udemy.com/course/microsoft-ai-extensions/
  • Introduction to Microsoft Semantic Kernel
    https://www.udemy.com/course/semantic-kernel