2012-05-12 1 views
0

В настоящее время я пишу Unit Test для проверки соединения между клиентом и сервером. На данный момент у меня есть следующие тесты; isConnectionSuccessful, isDisconnectionSuccesful и isReconnectionSuccesful.Использует геттер, но не назначает неправильное использование возвращаемого значения?

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

Согласны ли вы с этим подходом и просто не присваиваете значение от геттера для isConnectionSuccessful или это ошибка дизайна?

Просто уточнить у меня есть следующие тесты/методы:

isConnectionSuccessful 
//call getConnectedClient 

isDisconnectionSuccessful 
//call getConnectedClient and assign it 
//disconnect logic.... 

isReconnectionSuccessful 
//call getConnectionClient and assign it 
//disconnect 
//reconnect 

getConnectedClient 
//instantiate client 
//check it is connected 
//return client 
+0

Я не вижу, как это не нужно, геттер должен вернуть значение. Если у вас есть геттер с именем 'getClient'; он должен вернуть объект клиента. –

+0

Да, вот в чем проблема; имеет смысл использовать его для тестов isDisconnectionSuccessful и isReconnectionSuccessful, поскольку они требуют клиентского объекта, но для теста isConnectionSuccessful, хотя код точно такой же, и имеет смысл мне просто вызвать метод для уменьшения повторения, который он приводит к клиенту возвращаемый объект, который isConnectionSuccessful ничего не делает. В результате я предполагаю, что это ошибка дизайна? – LDM91

ответ

1

Я думаю, что вы говорите о модульном тестировании дизайна здесь. Если это так, тесты следуют несколько иным правилам, чем основной источник. Ваши основные цели в тестах состоят в том, чтобы тест был легко понятен и обеспечивал «защитную сетку» для поддержки изменений в тестируемом коде. Чтобы применить эти цели к вашему вопросу, читателю может быть непонятно, что getConnectedClient выполняет проверку соединения и, следовательно, это единственное, что необходимо в тесте isConnectionSuccessful. Это может быть аргументом для написания этого теста по-разному. С другой стороны, если вы чувствуете, что тест легче понять, как это происходит, то, возможно, вам просто нужно изменить имя getConnectedClient на что-то вроде connectClientAndVerifyConnection.

+0

Первоначально цель метода заключалась в том, чтобы вернуть клиента, который был проверен, чтобы быть уже подключенным для использования в тестах isDisconnectionSuccessful и isReconnectionSuccessful, после того, как я создал его, я понял, что код, который я использовал в тесте isConnectionSuccessful, соответствует тому, что находится в метод getConnectedClient. Таким образом, я думал, что могу уменьшить повторение в тесте isConnectionSuccessful, просто вызвав getConnectedClient, но он возвращает клиента, для которого не используется isConnectionSuccessful. – LDM91

+0

Таким образом, сокращение повторения является одной из тех вещей, которые мы стараемся использовать в основном источнике, но меньше заботимся об испытаниях. В тестах читаемость может превзойти повторение. Я бы сказал, что это призыв к суду для вас. Лучшее, что вы, вероятно, можете сделать, это спросить кого-то, кто работает с вами, что более понятно. –

+0

Возможно, я просто подумал об этом. Книга TDD, о которой я говорю, реорганизует, чтобы уменьшить повторение в тестах, а также в основном источнике, но я думаю, это зависит от меня, чтобы принять решение, как вы сказали, поскольку вы правы, это не так читаемо в данный момент. – LDM91