Я не хочу assertJ assertThat завершает тест, когда утверждение не удается - PullRequest
Новая
       15

Я не хочу assertJ assertThat завершает тест, когда утверждение не удается

0 голосов
/ 13 июня 2018

Я использую assertJ и имею несколько assertThat утверждений в моем тестовом примере.Когда первое утверждение не проходит, тест заканчивается, но я этого не хочу.Я хотел бы получить информацию обо всех ошибочных утверждениях после одиночного выполнения контрольного примера.Есть ли способ сделать это?Я нашел решение с помощью SoftAssertions здесь -> http://joel -costigliola.github.io / assertj / assertj-core-features-highlight.html # soft-assertions , но добавлять некую переменную некрасиво. перед каждым assertThat

Ответы [ 3 ]

0 голосов
/ 14 июня 2018

Если вам не нравятся мягкие утверждения, вы можете попробовать JUnit 5 assertAll , но в противном случае я бы следовал совету @GhostCat и пытался утверждать одну вещь за тест (это обычно приводит только кнесколько утверждений).

0 голосов
/ 14 июня 2018

Я думаю, что в некоторых случаях вы можете , а иногда даже вам приходится утверждать несколько вещей в одном методе теста, если ваш метод выполняет несколько изменений, которые вы должны проверить на разных уровнях/abstractions.
Например, когда вы тестируете метод, который добавляет элемент в объект, который его хранит, вы можете утверждать, что количество элементов, содержащихся в объекте, было увеличено на единицу, но вы также можете проверить, что новый элемент былправильно добавлено относительно его значений.
У вас есть два уровня / абстракции: объект, который содержит элемент, имеющий состояние "direct / core", и элементы, которые он содержит, которые имеют свои собственные состояния.

Разделив его на два утверждения, можно получить тест, который выглядит следующим образом: 

@Test
public void addElt(){
    foo.addElt(new Element("a name", "a role"));

    assertThat(foo).extracting(Foo::getSize)
                   .contains(actualSize+1);    
    assertThat(foo.getLastElt()).extracting(Element::getName, Element::getRole)
                                .containsExactly(addedElt.getName(), addedElt.getRole());
}

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

assertThat(foo).extracting(Foo::getSize)
               .contains(actualSize+1);

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

assertThat(foo.getLastElt()).extracting(Element::getName, Element::getRole)
                            .containsExactly(addedElt.getName(), addedElt.getRole());

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

То, что я пытаюсь объяснить, верно для AssertJ, как и для любой среды тестирования.

0 голосов
/ 13 июня 2018

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

Значение: идеяпроваленный тест - это как можно быстрее решить проблему.Когда вы объединяете несколько утверждений в один тест, по умолчанию вы усложняете нашу жизнь.Потому что вместо того, чтобы знать, что «тест X с утверждением Y провалился, вы должны сначала внимательно изучить журналы, чтобы определить, какие утверждения пройдены, а какие - нет.

Поэтому рекомендуется использовать , а не положить несколько подтверждений / проверок в одном тесте.

...