C#

Рекламный модуль
В продажу поступили двусторонние алмазные бруски для заточки.

Создание проверочного кода для метода Add ()

Проверочный код — это код вызывающей стороны, который передает параметры с определенными значениями и ожидает предусмотренный ответ. Если вызывающая сторона не получает предусмотренного ответа, то реализация проверяемого метода не¬верна. На рис. 2.8 демонстрируется типичный код вызывающей стороны, который про¬веряет работу метода Add () (мы добавим это в проект позже). Вызывающий код проверки похож на код, приведенный в предыдущем разделе. Различие в том, что проверочный код использует определенные переменные и значения, в то время как другой код может содержать любые переменные и значения. Еще одно требование проверочного кода — он должен проверять ответы, возвращаемые методом. ■ Для проверки используется оператор if, он выясняет, равно ли значение переменной total трем. Когда вы пишете проверочный код, его способ использования метода Add () должен быть тем же, что и у консольного приложения или приложения Windows. В противном случае это будет напоминать проверку зимних покрышек в пустыне Сахара — забавно, но бессмысленно. Код верификации в проверке немного специфичен. Возможно ли проверить ответ в рабочем коде? Возможно. Когда вы пишете код верификации в сценарии проверки, вы обеспечиваете стопроцентную верификацию. Когда вы пишете код верификации в ра¬бочем сценарии, вы проверяете вообще. Например, вы могли бы проверить достовер¬ность данных или просто их наличие. Другой вопрос, связанный с проверкой, относится ко времени проверок. Следует ли создавать их до или после реализации метода Add () ? Чтобы получить полное представ¬ление о проблеме, вообразите разработку шины. Проверку для глины задают до или по¬сле того, как она будет'разработана? Наиболее вероятные ответы: до, в течение и после разработки. Это важно учитывать при разработке программного обеспечения. Проверки пишут до, в течение и после реализации следующим образом. • Вы разрабатываете проверки перед реализацией метода, чтобы выяснить, ка¬кие пространства имен, классы и методы вы будете использовать. Определение всех элементов дает разработчику представление о том, как элементы будут использоваться. • Вы разрабатываете проверки в течение реализации метода, чтобы контролиро¬вать правильность реализации исходного кода. • Вы разрабатываете проверки после реализации метода, чтобы удостовериться в наличии всех точек над i в реализации.