Словарик философствующего информатика/Тестирование: различия между версиями

Как только у нас появляется текст программы, мы сразу хотим начать его тестирование. Крошечные пескарики имеют отвратительную привычку быстро становиться огромными акулами-людоедами, а поймать акулу намного сложнее. Но мы не хотим осуществлять все это тестирование вручную. Многие команды разрабатывают сложные планы тестирования своих проектов. Иногда они даже их используют. Но мы обнаружили, что команды, использующие автоматизированные процедуры тестирования, имеют больше шансов на успех. Тесты, запускающиеся в ходе каждого процесса сборки, являются более эффективными по сравнению с планами тестирования, которые лежат на полке. Чем раньше обнаружен дефект, тем дешевле обходится его устранение. «Чуть-чуть напишешь, чуть-чуть проверишь» — популярное изречение в мире [[Smalltalk]], и мы можем принять эту мантру как нашу личную, создавая одновременно (или даже раньше) с написанием рабочей программы программу ее тестирования. На самом деле удачный проект содержит больше программ тестирования, чем рабочих программ. Временные затраты на написание тестовой программы себя оправдывают. В конечном счете это оказывается намного дешевле, и вы действительно имеете возможность создания практически бездефектного продукта. Кроме того, осознание, что вы прошли тест, дает вам большую степень уверенности в том, что этот фрагмент программы готов.

 

 

На сайте extreme Programming эта концепция обозначена как "непрерывная интеграция, безжалостное тестирование". Тот факт, что вы закончили работу с фрагментом программы, вовсе не означает, что можно идти к шефу или заказчику, чтобы сообщить ему о "готовности". Фрагмент не готов. Прежде всего, программа в реальности никогда не бывает готовой. И, что более важно, пока она не пройдет все имеющиеся тесты, вы не можете утверждать, что она может использоваться кем бы то ни было. Следует рассмотреть три основных аспекта тестирования в масштабе всего проекта: что тестировать, как тестировать и когда тестировать.