Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Бек К. -> "Экстремальное программирование: разработка через тестирование " -> 58

Экстремальное программирование: разработка через тестирование - Бек К.

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 52 53 54 55 56 57 < 58 > 59 60 61 62 63 64 .. 81 >> Следующая


Сразу же после самого низкого уровня комментариев располагается исходный код теста.

1 McConnell, Steve. 1993. Code Complete, chapter 4. Seattle, Washington: Microsoft Press.

2 Caine, S. H., Gordon, E. K. 1975. PDL: A Tool for Software Design, AFIPS Proceedings of the 1975 National Computer Conference.

3 В среде англоязычных программистов запись базы данных иногда обозначается термином tuple — кортеж. — Примеч. перев.

Exception Test (Тест исключения)

Каким образом можно протестировать ожидаемое исключение? Перехватите исключение и игнорируйте его, сбой теста происходит только в случае, если исключение не сгенерировано.

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

public void testRateO {

exchange.addRate("USD". "GBP". 2);

int rate= exchange.fіndRate("USD". "GBP"):

assertEquals(2. rate);

' }

Тестирование исключения может оказаться неочевидным. Вот как мы это делаем:

public void testMissingRateO { try {

exchange.fіndRate("USD". "GBP"); failO:

} catch (IllegalArgumentException expected) { }

}

Если метод findRate() не генерирует исключения, произойдет обращение к методу fail() — это метод xUnit, который докладывает о том, что тест не сработал. Обратите внимание, что мы перехватываем только то исключение, которое должно быть сгенерировано методом findRate(). Благодаря этому, если будет сгенерировано какое-либо другое (неожиданное для нас) исключение (включая сбой метода assert), мы узнаем об этом.

All Tests (Все тесты)

Каким образом можно запустить все тесты вместе? Создайте тестовый набор, включающий в себя все имеющиеся тестовые наборы, — один для каждого пакета (package) и один, объединяющий в себе все тесты пакетов для всего приложения.

Предположим, вы добавили подкласс класса TestCase и в этот подкласс вы добавили тестовый метод. В следующий раз, когда будут выполняться все тесты, добавленный вами тестовый метод также должен быть выполнен. (Во мне опять проснулась привычка действовать в стиле TDD — должно быть вы заметили, что предыдущее предложение — это эскиз теста, который я, наверное, написал бы, если бы не был занят работой над данной книгой.) К сожалению, в большинстве реализаций xUnit, равно как и в большинстве IDE, не поддерживается стандартный механизм запуска абсолютно всех тестов, поэтому в каждом пакете необходимо определить класс AIITests, который реализует статический метод suite(), возвращающий объект класса TestSuite. Вот класс AIITests для «денежного» примера:

public class AllTests {

public static void main(String[] args) {

juni t.swi ngui.TestRunner.run(Al 1 Tests.class):

}

public static Test suiteO {

TestSuite result= new TestSuiteC'TFD tests"): result.addTestSuite(MoneyTest.class): • result.addTestSui te(ExchangeTest.class); result .addTestSuiteddentityRateTest. class): return result;

}

}

Вы также должны включить в класс AIITests() метод main(), благодаря чему класс можно будет запустить напрямую из IDE или из командной строки.

Паттерны проектирования

В чем заключается основная идея паттернов? Нам кажется, что мы постоянно сталкиваемся с разнообразными, не повторяющимися проблемами, однако на деле оказывается, что большая часть проблем, которые нам приходится решать, обусловлена используемыми нами инструментами, но не основной задачей, которая перед нами стоит1. Если исходить из этого предположения, то можно найти (и мы действительно находим) общие проблемы со стандартными решениями, несмотря на все разнообразие контекстов, в рамках которых нам приходится работать.

Использование объектов для организации вычислений — это один из лучших примеров стандартного решения, направленного на устранение множества общих проблем, с которыми программистам приходится сталкиваться при разработке самого разнообразного программного обеспечения. Колоссальный успех паттернов проектирования (design patterns) является доказательством общности проблем, с которыми сталкиваются объектно-ориентированные программисты2. Книга Design Patterns (Паттерны проектирования) имела большой успех, однако популярность этой книги стала причиной сужения взгляда на паттерны проектирования. Что я имею в виду? Книга рассматривает дизайн как фазу разработки программы, однако авторы совершенно не учитывают, что рефакторинг — это мощный инструмент формирования дизайна. Дизайн в рамках TDD требует несколько иного взгляда на паттерны проектирования.

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

1 Alexander Christopher. 1970. Notes on the Synthesis of Form. Cambridge* MA: Harvard University Press.

2 Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John. 1995. Design Patterns: Elements of Reusable Object Oriented Software. Boston: Addisoh-Wesley. Русское издание: Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2001.
Предыдущая << 1 .. 52 53 54 55 56 57 < 58 > 59 60 61 62 63 64 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100