Крюк SVN для проверки изменений также был внесен в соответствующий класс Test

Question

Кто-нибудь сталкивался с ловушкой предварительной фиксации SVN, которая работает со следующей логикой?

Если «MyClass.java» был изменен и находится в процессе фиксации, то также должна быть модификация «MyClassTest».java ", по соглашению об именах.

Цель здесь - убедиться, что разработчик внес изменения в соответствующий модульный тест, когда он / она изменил фрагмент кода.

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

Бонусом будет, если изменение является просто рефакторингом, за крючок, который игнорирует проверку, если отправляющий комментарий имеетслово "РЕФАКТОР".(ведь чистые рефакторы всегда должны совершаться сами собой)

Answer 1

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

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

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