Живое обучение кодированию – 20 июня 2019 г.

Я не транслировал сегодня, но просматривал некоторые из моих прошлых потоков (добывал их для контента для моих клиентов Java coaching) и понял, что мое правило кодирования, о котором я упоминал ранее, было неполным. Правило, которое я изложил, было:

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

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

Тесты должны проходить перед рефакторингом и оставаться проходящими – без изменений – после рефакторинга.

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

Например, если у меня есть код

public int price() {
  return cachedPrice;
}

Тогда для тестов или другого кода не должно иметь значения, изменил ли я его на:

public int price() {
  int sum = 0;
  for (Item item: items) {
    sum += item.price();
  }
  return sum;
}

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

Если тесты полагаются на то или иное поведение, то это, скорее всего (хотя и не всегда) проблема, из-за которой вы, возможно, захотите переосмыслить свой тестовый код.

Будьте уверены и настройтесь на мой следующий прямой эфир по кодированию: https://twitch.tv/jitterted .

Оригинал: “https://dev.to/jitterted/live-coding-learnings-june-20-2019-43g1”