Когда я должен разработать и задокументировать мои тестовые случаи?

Question

В SDLC, процедура тестирования должна быть сразу после внедрения.Тем не менее, разработка через тестирование побуждает нас проводить тестирование во время реализации.И в моем лекционном курсе Проф сказал, что тестовые наборы должны быть частью проекта.

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

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

Кроме того, в моих тестовых случаях я должен тестировать все части кода?ИЛИ просто проверить функциональность этого запроса функций?ИЛИ это на самом деле зависит от того, сколько времени у тебя есть?

Большое спасибо.

Answer 1

На ваш вопрос не так просто ответить, потому что, как вы говорите, «на самом деле это зависит от того, сколько времени у вас есть». Вот некоторые мнения:

Тест после реализации: Нет

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

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

Проверка при внедрении: Да

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

Это также особенно полезно при работе над большим проектом. Запуск модульного теста, чтобы увидеть, работает ли маленький модуль, происходит мгновенно. Сборка и загрузка всего приложения, чтобы увидеть, работает ли маленький модуль, может занять несколько минут. Это также может нарушить вашу концентрацию (которая стоит не менее 10 минут).

Что тестировать: Насколько это возможно

100% тестовое покрытие, вероятно, никогда не практично. Но обязательно протестируйте критические части вашей программы, вещи, которые выполняют математические вычисления или много бизнес-логики. Проверьте все, что осталось, как можно больше. Нет причин проверять функцию «toString ()», если только это не имеет решающего значения для бизнес-логики или чего-то подобного.

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

Answer 2

Мой опыт:

1. Документируйте свои тесты, если код не требует пояснений или если тестируемый случай является «хитрым» угловым случаем, который не очевиден на первый взгляд (хотякод может быть).
2. Не создавайте отдельные документы для ваших тестов.Поместите все в комментариях и Javadocs, если вы используете Java.Другими словами, держите эту информацию близко к коду.Вот где это необходимо.
3. О проектировании и реализации: просто итерируйте.Напишите некоторую реализацию, затем немного тестирующего кода для нее, затем больше кода реализации и т. Д., Пока вы не закончили и с реализацией, и с тестовым кодом.Это идет быстрее, чем написание всей реализации, затем тестирование, а затем переписывание ошибочного кода реализации.Вы не можете предвидеть все тесты, которые нужно реализовать во время разработки, это невозможно.Так что не беспокойтесь, если вы не получите всего этого.
4. Если вы охватите более 80% кода, то вы уже хороши, чем больше, тем лучше.Иногда код не может быть протестирован.Я рекомендую использовать инструменты тестирования покрытия, такие как Emma для Java.

ИЛИ на самом деле это зависит от того, сколько времени вы получили?

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