Вопросы о TDD и модульном тестировании

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

Чтобы взглянуть на вещи:

  1. Проекты, над которыми я работаю, небольшие
  2. Я единственный разработчик в указанном проекте (обычно)
  3. Все проекты на заказ.

То, что я не получаю больше всего, как может модульный тест рассказать мне, будет ли моя функция вычисления цены (что может зависеть от таких вещей, как день недели и праздничные дни и т. д., поэтому предположим, что 20-40 строк для эта функция) правильна? Не станет ли мне быстрее писать весь код и сидеть через сеанс отладки, чтобы каждый раз тестировать код?

Любые примеры, основанные на формах, будут оценены (примеры, которые я видел из видео MSDN, - это все MVC и пустая трата времени IMHO).

6 голосов | спросил Stuart Blackler 17 J000000Sunday11 2011, 20:08:58

4 ответа


23
  

То, что я не получаю больше всего, как может модульный тест сказать мне,   моя функция расчета цены (которая может зависеть от таких вещей, как день   недели и банковских праздников и т. д., поэтому предположим, что для этого 20-40 строк   функция) правильно? Не станет ли мне быстрее писать все   кода и сидеть через сеанс отладки, чтобы каждый раз тестировать   кода?

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

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

Как TDD защитит вас от этих проблем? Вы начинаете с написания простейшего случая и простейшего кода, который его передаст. Скажем, ваша цена по умолчанию - 7 долларов. Я напишу этот Java-ish, потому что это удобно, но подход работает на любом языке:

public void testDefaultPrice() throws Exception {
    assertEquals(7, subject.getPrice());
}

public int getPrice() {
    return 7;
}

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

Теперь мы скажем, что стоимость выходных дней должна составлять 9 долларов США. Но прежде чем мы сможем туда добраться, нам нужно знать, какие дни составляют выходные.

public void testWeekend() throws Exception {
    assertTrue(Schedule.isWeekend(Weekday.Sunday));
}

public boolean isWeekend(Weekday.Day day) {
    return true;
}

До сих пор так хорошо - и все еще очень неполно.

public void testWeekend() throws Exception {
    assertTrue(Schedule.isWeekend(Weekday.Sunday));
    assertTrue(Schedule.isWeekend(Weekday.Saturday));
    assertFalse(Schedule.isWeekend(Weekday.Monday));
}

public boolean isWeekend(Weekday.Day day) {
    return day == Weekday.Sunday || day == Weekday.Saturday;
}

Добавьте столько утверждений, сколько вам нужно, чтобы убедиться, что вы применили метод к правильности.

Теперь вернемся к нашему первоначальному классу:

public void testDefaultPrice() throws Exception {
    assertEquals(7, subject.getPrice());
}

public void testWeekendPrice() throws Exception {
    subject.setWeekday(Weekday.Sunday);
    assertEquals(9, subject.getPrice());
}

public int getPrice() {
    if (Schedule.isWeekend(day))
        return 9;
    return 7;
}

И так оно и есть. Также обратите внимание, как мы тестируем дизайн нашего кода здесь, и насколько это лучше из-за этого. С вашим подходом большинство программистов построили код тестирования на выходные в теле getPrice(), но это не то место для него. Множество кода, возможно, захочет узнать, будет ли день в выходные дни; таким образом, у вас есть это в одном, хорошо проверенном месте. Это способствует повторному использованию и повышает ремонтопригодность.

ответил Carl Manaster 17 J000000Sunday11 2011, 21:19:38
11

"сидеть в сеансе отладки, чтобы каждый раз тестировать код?" может быть быстрее ...

В первый раз.

Когда вам нужно вернуться и что-то изменить, вам придется провести еще один сеанс. Затем две недели спустя они хотят, чтобы что-то изменилось, и вам придется провести еще одну сессию.

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

ответил Marjan Venema 17 J000000Sunday11 2011, 20:26:58
3
  1. Скорее всего, вам не будет проще использовать отладчик и выполнить шаг через каждое условие и отслеживать входы и выходы.
  2. То, что вы получаете, - это тест, который вы можете продолжить в будущем после внесения каких-либо изменений в ваш код. Скажем, вы добавляете новый условие для вашей функции расчета цены в будущем, и это происходит, чтобы инвертировать одно из ваших других условий, что ваше программное обеспечение полагается - неудачный единичный тест будет вашей спасительной грацией. Вам не нужно было думать о переходе в отладчик и повторном тестировании каждого условия.

IMHO действительно сложно оценить ценность модульных тестов в вашей позиции, особенно потому, что вы работаете только с вашими проектами.

Я попробовал бы книгу для более подробной информации о преимуществах и методах тестирования:

http://www.amazon.com/Art-Unit-Testing-Examples-Net/дп /1933988274 /исх = sr_1_1 т.е. = UTF-8 & амп;? QID = 1310919437 & амп; ср = 8-1

ответил rkaregaran 17 J000000Sunday11 2011, 20:19:23
0

Хорошо, что вы спросили :) Итак, почему TDD? Можете ли вы попробовать ответить на следующие вопросы, чтобы узнать, можете ли вы оценить причины TDD.

  1. Проект небольшой. Означает ли это, что вы знаете каждый бит логики, лежащий в основе написанной вами функции, и почему вы так закодированы?
  2. Если ваш ответ «да», давайте попробуем сделать еще один шаг, связав другой факт, о котором вы заявили, - вы - одинокий разработчик в своем проекте - ВРУЧНУЮ. Как вы думаете, вы всегда будете помнить, почему у вас есть логика кода на месте, когда вы смотрите на нее?
  3. Является ли ваш ответ «да», давайте возьмем его немного дальше. Сколько времени вам нужно, чтобы вспомнить ответ на последний вопрос?

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

Помимо всего прочего, следующие причины, по которым вы практикуете TDD:

  1. ИСПЫТАНИЯ, ПОДТВЕРЖДАЮТ КОД, ЧТО ВЫ НАПИСАЛИ. Это помогает не только вам в более поздний момент времени, но и любому разработчику, который должен был работать над проектом, чтобы выяснить цель конкретного фрагмента кода.
  2. Написав тесты, вы программируете защитно. Могут быть ситуации, когда вы захотите перефразировать код или добавить новую функциональность или исправить ошибку. Это тестовый комплект, который (если он написан правильно) защитит вас от злополучной ошибки, которая возникает из-за условия, в производстве (которое вы по какой-то причине не тестировали в непроизводственных средах). Это неприятная вещь, чтобы получить избиения со всех углов, когда что-то идет не так в производстве, и это обычно происходит. Как это сделать, насколько возможно, в ZERO. ПОЛУЧИТЕ ОБЕСПЕЧЕНИЕ. НАПРАВЛЯЙТЕ ПРАВУЮ НАСТРОЙКУ ИСПЫТАНИЙ.
  3. В конечном итоге защитное кодирование улучшает качество кода и повышает производительность.
  4. Тесты - это более быстрые способы рутинного ручного тестирования на основе некоторого контрольного списка. Ручное тестирование может быть разведочным - тестирование необычного материала. Тесты вашего подразделения действуют как набор регрессии для ваших тестов на дым. Вы можете направить легендарного человека, Бликки Мартина Фаулера на модульное тестирование, чтобы узнать больше об этом.
  5. Если вы сначала сделаете пурист TDD - сначала запишите тесты, а затем - код, вы лучше поймете, что собираетесь писать, и убедитесь, что вы пишете только столько кода, что необходимо. Вы также испытаете эволюционные улучшения дизайна, которые приводятся в результате тестов.
ответил karthiks 17 J000000Sunday11 2011, 21:58:35

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132