2015-09-24 4 views
-1

Я являюсь персоналом QA банка в моей стране. У нас есть много приложений с устаревшим кодом, который действительно старый и не был протестирован с белым ящиком. Здесь мы также регулярно получали проекты и изменения в этом коде по просьбе бизнес-единицы.Создание теста JUnit для устаревшего кода

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

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

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

+0

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

+0

Да, это то, что мы думали - добавьте единичный тест для новых изменений. Но забота разработчика заключается в том, что если метод, который мы тестировали, терпит неудачу, и метод ссылается на другой класс, который они не знают. Что ты думаешь об этом? – Reinaldo

+0

О да, еще одна вещь. Разработчик также сказал, что невозможно добавить модульный тест к устаревшему коду. Мы должны создать единичный тест с самого начала, а не посередине. Правильно ли это? Потому что я все еще думаю, что это выполнимо. – Reinaldo

ответ

0

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

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

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

+0

После этого код и приложение будут функционально протестированы, поэтому я думаю, что не имеет значения, пропустим ли мы возможности регрессии. Без единичного теста мы также пропустили регрессионное тестирование, верно? Но я согласен с вашей точкой зрения о создании документации для долгосрочной разработки. Единичный тест поможет быстрее протестировать код в долгосрочной перспективе. О критических сценариях, мы потом подумаем, потому что мне нужно больше спросить разработчика. Итак, что вы думаете о добавлении модульного теста для новых изменений? Я буду отмечать ваш ответ правильно, если вы дадите дальнейшее мнение. Thx – Reinaldo

+0

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

+0

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

Смежные вопросы