Напишите пример класса на Java для хранения клиента с множеством счетов и их статусов

Что проверяют

Читаете ли вы код и, что важнее для тестировщика, видите ли в модели дыры, которые завтра станут багами. Ждут не идеального ООП, а списка проверок: какие статусы бывают, какие переходы разрешены, что происходит с деньгами.

Как отвечать

Покажите минимальную модель и сразу комментируйте решения:

public enum AccountStatus { ACTIVE, BLOCKED, CLOSED }

public class Account {
    private final String number;
    private BigDecimal balance;
    private AccountStatus status;
    public void close() { /* запрет при ненулевом балансе */ }
}

public class Client {
    private final String id;
    private final List<Account> accounts = new ArrayList<>();
    public void addAccount(Account a) { /* проверка уникальности номера */ }
    public List<Account> getAccounts() { return List.copyOf(accounts); }
}

Скажите вслух, почему так: деньги это BigDecimal или целое число копеек, статус это перечисление, а не строка, поэтому невалидное значение просто нельзя создать. Геттер отдаёт копию, иначе список пополнят мимо проверок. И сразу назовите тест-кейсы: клиент без счетов, два счёта с одинаковым номером, закрытие счёта с остатком, операция по заблокированному счёту, возврат из CLOSED в ACTIVE.

Где спотыкаются

Хранят баланс в double. Сложение долей копейки накапливает ошибку, суммы по счетам перестают сходиться с общей, и баг всплывает не в коде, а в отчётности через месяц после релиза.

Отдают внутренний список наружу как есть. Вызывающий код добавляет и удаляет счета напрямую, обходя любые проверки класса, и инварианты держатся только на договорённости.

Описывают набор статусов, но молчат про переходы. Тестировщик, который не спросил, можно ли открыть закрытый счёт и снять деньги с заблокированного, пропустит самые дорогие дефекты: они живут именно в переходах, а не в самих значениях.