Member Avatar for Ivzirnalsradeys

A large program has been written for a company which rents out properties to tenants for long or short periods.
There are separate data files which hold information about
A the tenants
B the properties
C the payments made by tenants
D the payments made by the company for the maintenance of the properties.
What will the programmer need to do and think about when designing test data for such a system?

  • 5 Contributors
  • 4 Replies
  • 193 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by David W

Dani AI

Generated

Practical checklist and concrete test-data ideas for the rental-management exercise described in the OP. The goals are to (1) exercise business rules, (2) verify cross-file links and integrity, (3) expose edge cases and date/number handling, and (4) make tests reproducible and automatable.

  • Functional / happy-path: representative tenant-property-payment sequences that follow normal workflows.
  • Referential-integrity failures: payments that reference missing tenants or properties; orphan maintenance records.
  • Temporal edge cases: leases that start/end on month boundaries, leap day, backdated or future payments, overlapping bookings.
  • Numeric and rounding issues: zero, negative, extremely large amounts, cents/precision and currency rounding.
  • Data-quality and format errors: missing fields, invalid dates, non-ASCII names, mixed encodings.
  • Business-rule violations: partial payments, double-bookings, early move-outs, prorated rents, refunds and adjustments.
  • Concurrency and idempotency: duplicate submissions, simultaneous payments, interrupted writes leaving partially-updated state.
  • Volume/perf: small canonical set for unit tests, and larger synthetic sets (10^3–10^6 rows) for reporting and backup/restore checks.
  • Privacy and provenance: if you reuse production extracts, mask PII and record when/why data was sampled.

Make datasets deterministic and versioned so CI can reproduce failures. Keep a tiny canonical fixture for unit tests and separate generators for integration/load tests. Use assertions that encode invariants (no orphan payments, balance closure, unique active tenancy per unit/date range). If the architecture looks awkward (as noted), write tests that reveal which invariants fail so the design problems become concrete.

Simple reproducible generator pattern (C++11) — seed the RNG so runs are repeatable:

// tiny reproducible CSV generator
#include <random>
#include <iostream>
#include <iomanip>

int main() {
    std::mt19937 rng(12345);
    std::uniform_int_distribution<int> id(1000,9999);
    std::uniform_real_distribution<double> amt(0.0,2000.0);
    for (int i=0;i<20;++i)
        std::cout << id(rng) << ",Tenant" << i << ",2024-02-" << ((i%28)+1)
                  << "," << std::fixed << std::setprecision(2) << amt(rng) << "\n";
}

As observed, the answer is broadly applicable; use the checklist above to convert the high-level concerns into repeatable test cases. The same scenarios apply regardless of storage technology (see ).

Recommended Answers

All 4 Replies

Member Avatar for Hiroshe

I thought the question was clear (and coincidentally straight forward). What part arn't you understanding?

Member Avatar for jwenting

All but the first and last lines are irrelevant to the question, actually. Apart from some implementation details the question has a universal answer that's applicable to all systems.

Member Avatar for gtcorwin

I would think about how I would slap the designer(s) in the head for this architecture

Member Avatar for David W

Any one want to suggest using SQL and linked tables ?

(Note: Python 3 now comes with SQLite ... and that might be a nice student way to begin a program to handle these linked data 'Tables' ?)

Edited by David W
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.