Циклическое тестирование зависимостей

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

Итак, я решил простую проблему, в которой у меня есть два класса, банк и счет. Банк содержит список со счетами, а счет содержит указатель на свой банк. Достигнута циклическая зависимость.

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

Класс Bank использует функции, которые делают что-то со счетами, например, переводят средства между ними, снимают или добавляют средства. И учетная запись содержит аналогичные функции, которые редактируют свои переменные.

Протестировать класс учетной записи легко, как создать экземпляр класса и протестировать функции, но как я могу протестировать класс, который зависит от другого класса, независимого от зависимости? И как вы проверяете отношения между двумя классами?

У меня возникли проблемы с поиском информации о циклических зависимостях, кроме того, что вам следует избегать их, но в более крупных проектах их трудно избежать.


c++ circular-dependency
person PSilo    schedule 17.08.2012    source источник
comment
возможный дубликат stackoverflow.com/q/10463001/819272   -  person TemplateRex    schedule 17.08.2012

Ответы (2)


arrow_upward
0
arrow_downward

Важный вопрос: зачем счету знать, какому банку он принадлежит? Трудно себе представить, чтобы операция по счету, требующая этой информации, не была бы лучше выполнена, чем операция с участием банка. Например, перевод денег с одного счета на другой обычно включает снятие банком А денег со счета АА и передачу их банку Б, который затем добавляет их на счет ВВ.

Возможно, вам нужно удалить зависимость, а затем выяснить, что «невозможно» без нее, и пересмотреть то, что вы пытаетесь сделать, и, возможно, переделать это с точки зрения того, что банк делает что-то со счетом, а не счет делает что-то с банком.

person Tom Tanner    schedule 17.08.2012

arrow_upward
0
arrow_downward

Попробуйте написать урезанную версию аккаунта

e.g.

class Account
{
   public:
      bool failDebit;
      bool Debit(unsigned int quid) { return failDebit;}
}

Затем вы можете проверить свой класс Bank, сначала установив failDebit для обоих случаев. Затем вы можете сделать его более сложным, если у вас есть более сложная функция в Bank, которая использует более одного Account, и протестировать класс Bank на все случаи жизни, используя аналогичный подход. Класс Account может быть очень простым и просто имитировать возвращаемые значения.

NB Это немного упрощенно, так как тогда могут быть зависимости между различными вызовами функций, которые, возможно, придется принимать во внимание (без каламбура).

person Ed Heal    schedule 17.08.2012