Команда Spring АйО перевела статью эксперта Михаила Поливахи о том, почему правило о единственном assert'е на тест иногда можно и нужно нарушать.

Я искренне верю, что большинство людей не совершают зла намеренно (хотя некоторые — да, совершают) Многие проблемы современного мира возникают из‑за недопонимания и различных точек зрения на те или иные вопросы, усугублённых человеческими эмоциями, культурными различиями и другими факторами.

В частности, я считаю, что афоризм:

«Дорога в ад вымощена благими намерениями»

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

Например, так называемое «правило единственного assert'а», изложенное в книге Clean Code, я нередко нахожу запутанным и даже непрактичным во многих случаях, связанных с разработкой программного обеспечения в целом.

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

Тем не менее, многие разработчики понимают это правило буквально — как требование иметь только один оператор assert в тесте. И мой совет вам — не следовать этому правилу слишком строго и отходить от него, если того требует ситуация.

Почему?

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

public class ConfigurationFactory {

  public static Configuration createInstance() {
    String javaVersion = System.getProperty("java.version");
    String user = System.getenv("USER");
    int cpusAvailable = Runtime.getRuntime().availableProcessors();

    return new Configuration(javaVersion, user, cpusAvailable);
  }

  static class Configuration {

    String javaVersion;
    String user; 
    int cpusAvailable;

    // constructor, getters etc.
  }
}

Приведённый выше пример — это Java-код, реализующий фабрику, которая создаёт объект, предварительно настраивая его. Этот шаблон, по крайней мере с точки зрения семантики, довольно распространён в разработке в целом.

Теперь допустим, что мы хотим протестировать метод createInstance() этой фабрики. И вот возникает вопрос — какое именно поведение мы хотим протестировать?

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

Но тогда возникает следующий вопрос — как именно мы будем проверять это состояние?

Следуя правилу

Если следовать «правилу единственного assert’а», то мне пришлось бы ограничиться единственной проверкой внутри теста. И тут становится очевидным: если я не хочу жертвовать качеством тестирования, мне нужно вручную создать экземпляр Configuration в рамках теста. А затем сравнить, совпадает ли внутреннее состояние этой вручную сконструированной Configuration с той, которую возвращает фабрика.

Проблема №1

В приведённом выше примере объект намеренно является достаточно компактным, т.к. служит для целей примера. Но если объект большой, то его ручное создание с, например, 30 полями будет абсолютно:

• Скучным (а это куда более серьёзная проблема, чем может показаться на первый взгляд)

• Подверженным ошибкам

• Трудным в сопровождении (представьте, как «весело» будет добавлять 31-е поле).

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

Есть и другая проблема: мне может потребоваться проверить только часть полей на точное соответствие. Например, если фабрика генерирует случайный UUID, я просто не смогу вручную создать тот же самый UUID в тесте — мне нужно лишь убедиться, что UUID:

• установлен фабрикой,

• и соответствует спецификации.

Проблема №2

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

Видите ли, я не знаю, на каком языке программирования вы пишете, но в Java по умолчанию при сравнении двух ссылок на объекты проверяется лишь то, указывают ли они на один и тот же участок памяти в heap-е Java процесса в рамках ОС.

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

Что можно сделать? Мы можем переопределить методы equals() и hashCode() в Java, чтобы сравнение происходило по содержимому полей, а не по ссылкам:

  static class Configuration {

    String javaVersion;
    String user;
    int cpusAvailable;

    // constructor, getters etc.

    @Override
    public boolean equals(Object o) {
      if (this == o) {
        return true;
      }
      if (o == null || getClass() != o.getClass()) {
        return false;
      }
      Configuration that = (Configuration) o;
      return cpusAvailable == that.cpusAvailable && Objects.equals(javaVersion, that.javaVersion) && Objects.equals(user,
          that.user);
    }

    @Override
    public int hashCode() {
      return Objects.hash(javaVersion, user, cpusAvailable);
    }
  }

Так что, хорошо ли это?
Нет. Это ужасно.

Почему всё так плохо? Потому что наш тестовый код начинает диктовать, как должен выглядеть продуктивный код. А этого никогда не должно происходить.

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

Решение

Просто пишите несколько assert’ов, если считаете это уместным. Не бойтесь.
Вас за это не посадят, честное слово.

В этом нет ничего сложного:

  @Test
  void testCreateInstance() {
    Configuration instance = ConfigurationFactory.createInstance();

    assertSoftly(softAssertions -> {
      softAssertions.assertThat(instance.getUser()).isEqualTo("my_user");
      softAssertions.assertThat(instance.getJavaVersion()).isEqualTo("17.0.4.1");
    });
  }

В результате вам не только не нужно создавать объект вручную, но и можно проверить только те поля, которые действительно вас интересуют, и на тех условиях, которые имеют смысл (вспомните пример с UUID). Вы не вынуждаете ваш класс Configuration переопределять equals()/hashCode() или подстраиваться под какие-либо особенности, нужные только для тестов.

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

Хорошего дня!

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.