Наш проект содержит 2600 файлов классов - где и как мы должны начать писать тесты Junit?

Question

Наш проект содержит 2600 файлов классов, и мы решили начать использовать автоматизированные тесты.

Мы знаем, что мы должны были запустить эти 2599 файлов классов назад, но как и где крупные проекты должны начать писать тесты?

Выберите случайный класс и просто отправляйтесь?

Что важно знать?Есть ли хорошие инструменты для использования?

Answer 1

Напишите юнит-тест перед тем, как что-то изменить, и для каждой обнаруженной ошибки.

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

Answer 2

Начните писать тесты для каждой поданной ошибки (напишите тест, посмотрите, как он провалится, исправьте ошибку, протестируйте снова).Также сначала протестируйте новые функции (они, скорее всего, будут иметь ошибки).Сначала это будет медленным, но по мере роста вашей тестовой инфраструктуры это станет легче.

Если вы используете Java 5 или выше, используйте junit 4.

Узнайте о разницеюнит-тесты, интеграционные и приемочные испытания.Также взгляните на насмешки.

Answer 3

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

So

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

Answer 4

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

«Если этот код сломается, сколько бы он не пососал» - хороший лакмусовый тест.

«Один из наших внутренних экранов обслуживания будет выглядеть плохо в IE6».«Мы отправим по 10 000 000 электронных писем каждому из наших клиентов», - другой ответ.

Какие классы вы бы сначала проверили, хе-хе.

Answer 5

Вы можете найти полезной книгу Майкла Перса Эффективная работа с устаревшим кодом .

Answer 6

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

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

Answer 7

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

http://my.safaribooksonline.com/0131177052

Answer 8

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