Вот ответ, который вы не хотели, но я думаю, что это правильный ответ:
- Напишите набор модульных тестов, которые вызывают каждый метод вашего API (у вас это уже есть, верно?: -)).
- Когда вы вносите изменение в API, перекомпилируйте новую версию вашего API, но не юнит-тесты.
- Запустите «устаревший» набор юнит-тестов для «свежий "API.Этот устаревший набор тестов становится канарейкой, имитируя ситуацию, в которой будут находиться клиенты вашего API.
Проблема first , связанная с простой перекомпиляцией всего кода клиента это то, что это может быть невозможно.Код может не принадлежать вам;это может быть пользовательский код, написанный одним из ваших клиентов и недоступный для вас.
Проблема second в простой перекомпиляции клиентского кода заключается в том, что иногда вы даже не получитеошибка компиляции, потому что код вызова не нужно менять.Однажды я столкнулся с такой проблемой.У меня был такой метод API:
public void doSomething(){
}
с кодом, который связан с ним.Я хотел изменить это на это:
public boolean doSomething() {
}
Так я сделал это и перекомпилировал.Не было никаких ошибок, потому что код, который вызвал первую версию doSomething()
, безоговорочно связывался с новой версией (отбрасывая возвращаемое значение, которое является допустимым в Java).Однако мало что я знал, что он изменил байт-код внешнего класса при перекомпиляции.Мы начали получать ошибки, когда API обновлялся, но код, использующий его, не перекомпилировался.
Поэтому вместо того, чтобы искать ошибки, мне следовало бы также посмотреть, какие внешние файлы в результате изменили свой байт-код.В этот момент я бы сказал, что вы должны просто использовать модульные тесты для этой цели, так как вы все равно должны их писать.