Интерфейс пользовательского интерфейса и TDD babysteps

Question

ОК, попробовав мою первую попытку TDD, пришло время немного задуматься и получить некоторое руководство, потому что это не было так успешно для меня. Решение было частично сделано с существующей структурой, возможно делая TDD менее идеальным. Часть, которая, казалось, дала мне самый большой проблема, было взаимодействие между представлением и контроллером. Больной приведу несколько простых примеров и надеюсь, что кто-то скажет мне, что я могу сделать лучше неправильно.

Интерфейс каждого представления наследуется от базового интерфейса, с этими участники (их больше):

открытый интерфейс IView
{
void ShowField (string fieldId)
void HideField (string fieldId)
void SetFieldVisibility (строка fieldId, bool видимый)
void DisableField (string fieldId)
void ShowValidationError (string fieldId)
...
}

Интерфейс для конкретного представления, затем будет добавлять элементы для каждого поле как это общедоступный интерфейс IMyView: IView
{
Имя строки {получить; задавать; }
string NameFieldID {get; }
...
}

Что вы думаете об этом? Наследует от общего интерфейса хорошая или плохая идея? Одна из вещей, которая доставляла мне неприятности, заключалась в том, что сначала я использовал ShowField и HideField и выяснил, я бы лучше использовать SetFieldVisiblity. Я не изменил результат метода, но я пришлось обновить мой тест, который, как мне кажется, должен быть необходим. Имеет несколько методов делают одно и то же, плохо? С одной стороны, оба методы удобны для разных случаев, но они загромождают интерфейс, что делает интерфейс более сложным, чем он должен быть.

Будет ли лучше дизайн без общего интерфейса? Что бы убрать fieldID, я не знаю почему, но я думаю, что FieldID-вещь пахнет, я может быть не так. Я бы делал только методы Show и Hide, когда это необходимо, то есть если они будут вызваны контроллером. Это было бы менее общим решение и требуют больше кода в представлении, но код контроллера было бы немного проще.

Итак, интерфейс представления может выглядеть так: общедоступный интерфейс IMyView
{
void ShowName ()
void HideName ()
Имя строки {получить; задавать; }
int Age {get; задавать; }
}

Answer 1

Ваш вопрос немного неясен для меня, но сам заголовок требует ссылку:

Диалоговое окно «Смирение»

И когда вы спрашиваете, плохо ли иметь две функции, выполняющие одно и то же, я отвечаю: «Да, это плохо». Если один вызывает другой, какой смысл иметь две функции? Если нет, у вас есть дублирование кода, то есть ошибка, ожидающая появления при обновлении одного, а не другого.

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

Answer 2

Что вы хотите проверить? Сможет ли Show * сделать виджет в интерфейсе видимым? Для чего?

Мое предложение: не пытайтесь выяснить, работает ли фреймворк правильно. Это пустая трата времени. Люди, которые разработали структуру, должны были сделать это, поэтому вы дублируете их работу.

Обычно вы хотите знать, правильно ли работает ваш код. Поэтому, если вы хотите знать, вызываете ли вы правильные методы, создайте макеты:

public class SomeFrameworkMockup extends SomeFramework {
    public boolean wasCalled;
    public void methodToTest() {
        wasCalled = true;
    }
}

Создайте пользовательский интерфейс, используя макеты.

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

Избегайте внешних рамок во время тестов. Это только смущает вас. Когда вы создали работающий продукт, протестируйте его с помощью мыши. Если вы обнаружите какие-либо проблемы, доберитесь до их корня и только потом начните писать тесты для фреймворка, чтобы убедиться, что эта ошибка не появится снова. Но в 90% случаев эти ошибки будут и в вашем коде.

Answer 3

В настоящий момент я не вижу добавленной стоимости общего интерфейса.

Я думаю, что лучшим решением было бы иметь некоторые свойства класса контроллера: IsControlXYZVisible. Затем вы можете связать свойство видимого элемента управления с этим свойством.

И ваш модульный тест проверит значение IsControlXYZVisible, которое будет легче выполнить.

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