Вы используете Поблочное тестирование в своих профессиональных проектах? [закрытый]
Переменные экземпляра, объявленные в вашем методе инициализации, должны быть теми, которые вы хотите установить во время инициализации. В вашем примере класса Person вам не нужно устанавливать @age при инициализации (на самом деле это вызовет ошибку, как у вас сейчас).
class Person
attr_accessor :name, :age
def initialize(name)
@name = name
end
def birthday
if @age.nil?
@age = 1
else
@age += 1
end
end
end
Надеюсь, это поможет. Если метод инициализации не имеет установленного возраста, вы все равно можете использовать / установить возраст в других методах. В этом случае при первом вызове метода Person.birthday он установит для @age значение 1, а затем увеличит его оттуда.
17 ответов
Абсолютно поблочное тестирование используется на наших проектах. Каждый класс, который не является глупыми методами считывания и методами set, протестирован на единицу. Наличие функциональных испытаний для Вас кодирует, позволяет Вам осуществить рефакторинг по желанию, не волнуясь, что Вы повредите 50 разных вещей сразу.
Другой недооцененный аспект поблочного тестирования - то, что оно поднимает пропущенные аспекты на поверхность алгоритма. Я просто провел два дня, пишущий и переписывая модульные тесты с помощью ортогональных массивов, потому что каждый раз я придумал список тестовых сценариев, я обнаружил еще один размер проблемы, которая была пропущена техническим выводом.
Я интересуюсь выполнением его, но не уверен, как начать делать его с крупными проектами, я заканчиваю тем, что присоединился к части путь через... Не были вовлечены в реальное начало с нуля проекта с тех пор назад в 1996!
На всей новой разработке мы теперь делаем TDD. Для обслуживания прежней версии мы создаем провальные модульные тесты, чтобы выставить дефекты, о которых сообщают, и постепенно создавать библиотеку.
Это - культурный шок, но это действительно окупается, когда Вы понимаете, что проводите больше времени на новой разработке и поиск ошибки меньшего количества времени.
Модульный тест (я думаю JUnit здесь), и TDD способ пойти, когда Вы запустите новый проект с нового кода (и Вам будет нужен больше как CI).
Но то, когда Ваш новый проект состоит в том, чтобы изменить старую кодовую базу, полную трудных двойных классов с 5KLOC в каждом из них затем, Поблочное тестирование является трудным, и большую часть времени временная шкала проекта не будет, позволило рефакторинг (или переписывание). Если это - вид проекта, Вы собираетесь запуститься, я рекомендую Вам считать "Работу С Унаследованным кодом" для стратегий тестирования относительно старого кода.
Да. За исключением случаев, когда у клиента есть оружие затем моя голова для вытаскивания функции из-за двери к концу дня.
Мне бы хотелось использовать поблочное тестирование больше в моем проекте, и мне жаль, что мои коллеги не писали по крайней мере некоторые тесты.:)
В моем случае существует довольно высокая цена за включение поблочного тестирования и использование методов TDD. Это главным образом зависит от инструментов, которые довольно плохи для платформы, которую мы используем. Если только поблочное тестирование, возможно, было выполнено одиночным нажатием для целого проекта (или два щелчка, в случае, если нам был нужен определенный тест в данный момент), это будет намного легче. Инструменты, которые мы используем теперь, действительно не окупаются — иногда легче определить ошибку вручную, вместо того, чтобы запустить тест.
С Java существуют лучшие инструменты, таким образом, действительно необходимо начать писать тесты теперь! Отладка сосет, тестируя скалы, действительно.
К сожалению, не каждый раз. Наше большинство систем в жестком реальном времени полно модульных тестов, чтобы гарантировать, чтобы они сделали то, что они должны сделать, и продолжать делать его независимо от разработчиков. Для других систем большую часть времени время разработки слишком коротко для расходов его на запись тестов. (однако в конце время, выигранное там, проводят два раза на отладке.)
Я нашел TDD действительно полезным, но некоторые разработчики не видят значение его до записи, что некоторый новый код повреждает более старый тест.
Мы делаем Поблочное тестирование после того, как раздел работ кода как клиент действительно будет требовать. Сначала мы делали Поблочное тестирование слишком быстро и когда клиент передумал (и оно происходит, доверяйте мне), часто необходимо удалять код, а также Модульный тест. Это было слишком трудоемким и дорогостоящим. Я для Поблочного тестирования, но TDD не был чем-то экономичным для нас.
Не TDD строго, но я делаю поблочное тестирование на каждой части кода, который я пишу. Я думаю о нем таким же образом, я думаю об управлении исходным кодом и рефакторинге; они - что-то, что Вы просто делаете для написания качественного кода. Я не думал бы не о поблочном тестировании.
Поблочное тестирование происходит в цену. Во-первых, необходимо записать и проверить весь тот дополнительный код. И затем Вам, вероятно, придется продвинуть дорогое изменение культуры в проектной группе охватывать поблочное тестирование.
Эту цену могло бы хорошо стоить заплатить за Ваш определенный проект. Решение не должно быть основано на догме или истории, но на тщательном анализе расходов и доходов.
Да. Мы использовали TDD некоторое время теперь. Так или иначе TDD стал найденным на нас, и нам нравится этот поэтапный подход для достижения лучшего качества кода. Несмотря на начальную кривую отказа, где Вы думаете, что она замедлит разработку, имеющую последовательное и прогрессивное поблочное тестирование, в то время как написание кода важно во многих отношениях. Запись повреждающихся изменений является очень трудной произойти из-за платформы тестирований регрессии, которая инкрементно создается. Когда сделанный исправляются, код более устойчив, и уверенность в коде и в целом проекте положительно затронута.
Запись модульных тестов в наше время не для простой элиты. Это должна быть каждая ответственность разработчика. Чем позже ошибка найдена на коде, тем больше это будет стоить для фиксации, и тяжелее это должно будет найти. Это легко становится кошмаром обслуживания. Наличие мощной поддержки модульных тестов высоко снижает этот риск.
Объединение питания модульных тестов и TDD с хорошо настроенной непрерывной системой интеграции допускает быстрое исследование проблем в ранних фазах проекта. Ежедневная сборка - необходимость для предотвращения будущего и почти верных стычек.
Я нахожу, что поблочное тестирование является больше, чем просто полезная вещь сделать, это - также ответственность разработчика. При выпуске кода, который не был написан для передачи допустимого и исчерпывающего набора модульных тестов, Вы могли задерживать свой проект или вызывать проблемы в чужих пакетах, классах, и т.д.
Кроме того, необходимо быть в тесном контакте с клиентом (даже если это - собственная компания), и попытайтесь поощрить их делать всесторонние приемочные испытания. Это находится в их интересах (хотя я нашел, что некоторые компании являются стойкими к идее, из-за краткосрочных издержек времени, требуемого выполнить тестирование, несмотря на количество времени, которое это сохранит, если продукт не сделает точно, что они хотят).
Править
Так, да, я предполагаю точку, которую я пытаюсь сказать: да, я действительно рассматриваю Разработку через тестирование как способ пойти. Другой вещью, которую я не упоминал, конечно, является то, что тесты помогают зарегистрировать код. Вы будете знать то, что методы, как предполагается, делают, и Вы будете уверены, что они все еще делают, когда Вы вносите изменения на любом более позднем этапе.
Когда Вы зададите вопрос на дискуссионном форуме, много людей скажет, что поблочное тестирование "обязательно", но в действительности соображение поблочного тестирования как шоу результатами обзора. См. http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2 для большего количества ссылок/материала.
Я не могу представить себе работу над проектом без автоматического тестирования (Unit / Integration и т. Д.)
На самом деле, я часто говорю
«Если это сломается, это не мое ошибка »
при работе с кодом людей, не имеющим тестов.
Да, везде, где могу. Я должен поддерживать код, который я пишу, и я знаю, что небольшое количество дополнительного времени, потраченного во время разработки, избавляет меня от нескромного количества дополнительного времени, потраченного после выпуска.