JUnit Тестирование для сценариев автоматического тестирования?

Question

Я недавно присоединился к этой организации, в которой я сейчас работаю, и попросил меня управлять проектом, чтобы пересмотреть, расширить и поддерживать существующую среду автоматизированного тестирования, написанную на Java, в которой используются основанная на ключевых словах структура и RFT. Я был разработчиком в глубине души всю свою жизнь, хотя я перешел на Agile менеджмент. По привычке я пишу модульные тесты для проверки поведения перед написанием исходного кода. Эта структура не имеет одного модульного теста. Мой первый инстинкт был "где юнит тесты?" Я знаю, что могу написать модульные тесты для классов инфраструктуры тестирования. Во время обсуждения здесь было сказано, что написание модульных тестов для тестирования фреймворков или скриптов может быть пустой тратой времени. Я дипломатически не согласен.

Вопрос 1. Может ли мой инстинкт ошибаться? Есть ли у вас какие-либо предложения, которые могут быть полезны для борьбы с моим делом.

Вопрос 2: И может ли это стать рекурсивным? Написание тестов для тестов и тестов и так далее. Есть ли правило для того, когда прекратить писать модульные тесты? Есть ли концепция тестирования рекурсии тестера?

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

EDIT

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

Answer 1

Если ваша организация написала этот фреймворк для тестирования, вам следует выполнить его модульное тестирование. Если вы используете существующую среду тестирования (например, JUnit), я бы не стал это тестировать. Оставьте это тестирование создателю инфраструктуры тестирования.

Итог: вы написали это, вы тестируете.

Answer 2

Вопрос 1. Может ли мой инстинкт ошибаться?Есть ли у вас какие-либо предложения, которые могут быть полезны для борьбы с моим делом.

Ваши инстинкты не ошибаются.Если в вашей среде тестирования есть ошибка, она может пропустить ошибки, например, пропуская тесты.

Вопрос 2: Может ли это стать рекурсивным?Написание тестов для тестов и тестов и так далее.Есть ли правило для того, когда прекратить писать модульные тесты?Есть ли концепция тестирования рекурсии тестера?

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

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

Answer 3

Было очень хорошее интервью с Кентом Беком по Радиостанция разработки программного обеспечения , где он объяснил свою философию о том, когда писать тесты, когда делать TDD и т. Д.

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

Чтобы ответить на ваш вопрос, задайте себе вопрос. Поможет ли вам рефакторинг, расширение, поддержка этой среды, если у вас есть тесты? Если да, напишите тесты.

1) Обычно, хорошая практика рекомендует писать тесты перед рефакторингом (чтобы убедиться, что поведение не меняется) или перед созданием нового кода (стандартное TDD).

2) Да, это может стать рекурсивным, но у вас есть только столько времени в течение дня, поэтому вам нужно подумать о том, какие усилия вы тратите на дополнительную ценность, которую вы вносите в проект.

Написание модульных тестов также поможет вам лучше понять существующий код. Лично я бы писал тесты.

Answer 4

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

Answer 5

Чтобы проверить что-то, вам нужна ссылка, с которой можно сравнить результаты. Для каркаса или сценария производственный код может использоваться в качестве справочного - если версии не совместимы: если все тесты пройдут с каркасом N и с каркасом N + 1, тогда нет [видимой] регрессии, будут ли все необходимые ограничения (при условии достаточного покрытия ...). Вот где написание модульных тестов для тестирования фреймворков или скриптов можно считать пустой тратой времени.

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

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