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

24. Ретроспектива xUnit 
Если перед вами встала зад ача разработки своей собственной
инфраструктуры тестирования, метод ика, описанная в части II д анной
книги, по служит вам руковод ством. Не след ует слишком много
внимания уд елять д еталям реализации – значительно больший интерес
пред ставляют тесты. Если вы напишете код , обеспечивающий успешное
выполнение пред ставленных зд есь тестов, в вашем распоряжении
окажется минимальная инфраструктура тестирования, пригод ная д ля
запуска тестов в условиях изоляции и обеспечивающая композицию
тестов. Вы сможете приступить к разработке программного код а в стиле
TDD.
На момент написания д анной книги инфраструктура тестирования
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 countTestCases();
public abstract void run(TestResult result);
}
В языках с оптимистическим (д инамическим) привед ением типов
можно д аже не объявлять о под д ержке этого интерфейса – д о статочно
реализовать вход ящие в его со став операции. При использовании языка
сценариев Сценарий может ограничивать реализацию countTestCases()
возвратом ед иницы и выполнять проверку TestResult на отказ, а вы
можете выполнять ваши сценарии с обычными объектами TestCase.

---