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

Гораздо лучше кодировать в тщательно подобранном вами стиле, чем полагаться на установки редактора по умолчанию. Этого может потре# бовать стиль, принятый в фирме. Я лучше настрою свой редактор, что% бы он автоматически форматировал код так, как мне нужно, чем буду мучиться с перемещением курсора после каждого нажатия ENTER.

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

5.Как вы определяете долю своего бюджета, предназначенную для при обретения инструментов? Как вы решаете, стоит ли инструмент своих денег?

Все зависит от того, в какой организации вы работаете и какого рода деятельностью занимаетесь. Если бюджет вашего проекта сравним с ВВП небольшого государства, тогда стоимость инструментов не име% ет значения – купите себе лучшие инструменты (они могут оказаться не самыми дорогими) и радуйтесь жизни. А вот одинокий хакер, рабо% тающий дома, не всегда может позволить себе самые высококлассные инструменты. Часто для домашнего употребления оказывается доста% точно свободно распространяемых инструментов.

На самом деле, бесплатно распространяемые инструменты часто отли% чаются очень высоким качеством, из%за чего трудно определить, в ка% ких случаях стоит раскошелиться на инструменты. Если вы платите за инструменты, то обычно можете рассчитывать на хорошую под% держку, а также исправление обнаруженных ошибок и доработку в бу% дущем. Однако это не всегда удается – компании закрываются, а вы% пуск продуктов прекращается. Это может быть аргументом в пользу выбора наиболее популярных и широко используемых инструментов. Численность спасает.

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

Глава 8. Время испытаний

Вопросы для размышления

1.Напишите комплект тестовых примеров для кода определения наи большего общего делителя, приведенного в начале главы. Постарай тесь проверить как можно больше случаев. Сколько отдельных конт

рольных примеров у вас получилось?

ставьте себе мучения из%за ошибок в тестовом коде!

2.Какие различия между тестированием приложения электронной таб лицы и системы автоматического пилотирования самолета?

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

итолько после этого сданы. На практике происходит немного иначе. Если можно смириться с тем, что электронные таблицы будут время от времени давать сбой,1 то автопилот не должен содержать никаких ошибок. Когда на карту ставятся человеческие жизни, программы разрабатываются совсем иным образом – гораздо более формально

игораздо тщательнее. Они строго тестируются. Действуют стандарты безопасности.

3. Нужно ли тестировать тестовый код, который вы пишете?

Если долго думать на эту тему, то голова заболит. Если начать тестиро% вать тестовый код, то как можно быть уверенным, что тестовый код для тестового кода вашего тестового кода корректен? Фокус в том, что% бы писать как можно более простые тесты. Тогда самой вероятной ошибкой тестирования станет отсутствие каких%то важных проверок, а не проблемы фактических строк тестового кода.

Пишите код тестов как можно проще, чтобы избежать в нем ошибок.

4.В чем разница между тестированием, проводимым программистом, и тестированием в отделе QA?

Тестеры чаще проводят тестирование в стиле черного ящика и обычно работают только с продуктом в целом. Они редко работают на уровне кода, потому что продукт обычно является исполняемой программой; библиотеки кода поставляются относительно редко.

Программисты чаще проводят тестирование в стиле «белого ящика», проверяя, что их творения работают в соответствии с замыслом.

Тайная задача любого программиста, пишущего тесты, – доказать, что его код работает, а не найти случаи, когда он не действует! Легко напи% сать кучу тестов, которые покажут, какой замечательный у меня код, сознательно избегая тех мест, которые кажутся мне подозрительны% ми. Это хороший аргумент в пользу того, что тестовые структуры дол% жен создавать не автор кода, а кто%то другой.

5.Нужно ли писать набор контрольных примеров для каждой отдельной функции?

1Жаль, но мы вынуждены с этим смириться.

Если ваш код использует особые возможности целевой платформы (многопроцессорность или специфическую аппаратуру), то полное тес% тирование в их отсутствие не провести. Можно воспользоваться эму% ляторами, чтобы убедиться в работоспособности кода, но окончатель% ного ответа они не дадут.

Опасно откладывать тестирование до того момента, когда станет до% ступна целевая платформа. К тому времени накопится большой объем кода, полностью проверять который у вас не будет ни времени, ни же% лания. Наибольшая надежность достигается, если тестирование про% водится как можно раньше.

9.Как определить, что проведено достаточно тестов? Когда можно оста новиться?

Тестирование не может доказать отсутствие дефектов, поэтому нельзя с уверенностью сказать, что оно проведено в достаточном объеме. Зада% ча может оказаться бесконечной, и хотелось бы предложить такой план тестирования, который оказался бы реалистичным.

Для простых блоков кода при тестировании методом черного ящика достаточно успешно выполнить все тесты из раздела «Выбор контроль% ных примеров для блочного тестирования» на стр. 200.

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

Тестирование по охвату

План тестирования определяется как мера охвата программы. На% пример, можно запланировать выполнить каждую строку кода хо% тя бы один раз, пройти каждую ветвь условных операторов или продемонстрировать хотя бы раз выполнение всех системных тре% бований.

Тестирование по количеству ошибок

Основано на фильтрации определенного процента программных ошибок. Задается гипотетическое количество ошибок – обычно ис% ходя из прежнего опыта. Затем вы решаете найти и обезвредить, скажем, 95% от этого числа.

Тестирование по типам ошибок

При этом подходе внимание обращается на те места, где чаще всего возникают ошибки. Например, тестируются все граничные значе% ния и выявляются все ошибки смещения на единицу.

Исходя из этого можно установить критерии прекращения тестирова% ния:

•Успешно проходит определенный процент регрессивных тестов (при этом неудачные тесты не являются определяющими).

•Охват кода, функциональности или требований достигает заданно%

го уровня.