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

 

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

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 34 35 36 37 38 39 < 40 > 41 42 43 44 45 46 .. 81 >> Следующая


На момент написания данной книги инфраструктура тестирования xUnit адаптирована для более чем 30 языков программирования. Язык, на котором вы программируете, скорее всего, уже обладает своей собственной реализацией xUnit. Однако даже если кто-то уже делал это до вас, возможно, будет лучше, если вы попробуете разработать свою собственную новую версию xUnit самостоятельно. Существует две важных причины:

• Контроль над реализацией. Основополагающая характеристика xUnit — это простота. Мартин Фаулер (Martin Fowler) сказал: «Никогда в истории программной индустрии еще не было случая, чтобы столь многие разработчики были обязаны столь немногому количеству строк программного кода». На мой взгляд, некоторые реализации xUnit к настоящему времени стали слишком большими и сложными. Если вы разработаете собственную версию xUnit, то получите инструмент, который вы будете контролировать в полном объеме.

• Обучение. Когда я сталкиваюсь с необходимостью изучить новый язык программирования, я приступаю к реализации xUnit. Когда я добиваюсь срабатывания первых восьми-десяти тестов, я овладеваю навыками работы с основными конструкциями и возможностями нового для меня языка.

Когда вы начнете работать с xUnit, вы обнаружите, что существует значительная разница между не сработавшими выражениями assert и ошибками других типов, возникающими в процессе выполнения тестов. В отличие от остальных ошибок выражения assert требуют больше времени для отладки. Из-за этого боль-

шинство реализаций xUnit отличает сбои операторов assert от всех остальных ошибок: в рамках GUI зачастую информация об ошибках отображается в начале списка.

Инфраструктура JUnit объявляет простой интерфейс Test, который реализуется классами TestCase и TestSuite. Если вы хотите создать тестовый класс, который мог бы взаимодействовать со стандартными средствами тестирования, встроенными в JUnit, вы можете реализовать функции интерфейса Test самостоятельно:

public interface Test {

public abstract int countTestCasesO: public abstract void runCTestResult result):

}

В языках с оптимистическим (динамическим) приведением типов можно даже не объявлять о поддержке этого интерфейса — достаточно реализовать входящие в его состав операции. При использовании языка сценариев Сценарий может ограничивать реализацию countTestCases() возвратом единицы и выполнять проверку TestResult на отказ, а вы можете выполнять ваши сценарии с обычными TestCases.

Часть HI

Паттерны для разработки через тестирование

Далее следуют «величайшие хиты» — паттерны для разработки, основанной на тестировании. Некоторые из них являются эффективными приемами работы в стиле TDD, другие являются паттернами проектирования, наконец, третьи — это рефакторинги. Третья часть книги является коллекцией справочного материала, необходимого как для освоения представленных в книге примеров, так и для самостоятельного совершенствования навыков работы в стиле TDD. Здесь представлены сведения, которые помогут вам лучше понять смысл примеров, рассмотренных в первых двух частях книги, а также подогреют ваш интерес и стимулируют обратиться к дополнительной информации, которую следует искать в других источниках.

Паттерны

разработки, основанной

на тестах

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

• Что такое тестирование?

• Когда мы выполняем тестирование?

• Какая логика нуждается в тестировании?

• Какие данные нуждаются в тестировании?

Тест

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

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

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

На рис. 25.1 представлена диаграмма взаимовлияния между стрессом и тестированием (она напоминает диаграммы Герри Вейнберга (Gerry Weinberg) в его книге Quality Software Management). Стрелка между узлами диаграммы означает, что увеличение первого показателя влечет за собой увеличение второго показателя. Стрелка с кружком означает, что увеличение первого показателя влечет за собой уменьшение второго показателя.
Предыдущая << 1 .. 34 35 36 37 38 39 < 40 > 41 42 43 44 45 46 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100