Нет родительского селектора; так же, как нет предыдущего селектора. Одна из веских причин не иметь этих селекторов заключается в том, что браузер должен пройти через всех дочерних элементов элемента, чтобы определить, следует ли применять класс. Например, если вы написали:
body:contains-selector(a.active) { background: red; }
Затем браузеру придется подождать, пока он не загрузится, и все разобрались до
Эта статья Почему у нас нет родительского селектора , это подробно объясняет.
Интересная вещь о assertAll заключается в том, что она всегда проверяет все утверждения, которые передаются ей , независимо от того, сколько неудач. Если все проходит, все нормально - если хотя бы один из них не получается, вы получите подробный результат всего, что пошло не так (и, если на то пошло).
Лучше всего использовать для утверждения набора свойств, которые принадлежат вместе концептуально.
Ваш конкретный пример не является оптимальным вариантом использования для assertAll, потому что проверка isPrime ] с простым и не-простым не зависит друг от друга - настолько, что я бы рекомендовал написать для него два метода тестирования.
Но предположим, что у вас есть простой класс, такой как адрес с полями city, street, number и хотели бы утверждать, что это то, что вы ожидаете от них:
Address address = unitUnderTest.methodUnderTest();
assertEquals("Redwood Shores", address.getCity());
assertEquals("Oracle Parkway", address.getStreet());
assertEquals("500", address.getNumber());
Теперь, как только первое утверждение не удастся, вы никогда не увидите результатов второго, что может быть весьма раздражающим. Существует много способов обойти это, и JUnit Jupiter assertAll является одним из них:
Address address = unitUnderTest.methodUnderTest();
assertAll("Should return address of Oracle's headquarter",
() -> assertEquals("Redwood Shores", address.getCity()),
() -> assertEquals("Oracle Parkway", address.getStreet()),
() -> assertEquals("500", address.getNumber())
);
Если проверенный метод возвращает неправильный адрес, это ошибка, которую вы получаете:
org.opentest4j.MultipleFailuresError:
Should return address of Oracle's headquarter (3 failures)
expected: <Redwood Shores> but was: <Walldorf>
expected: <Oracle Parkway> but was: <Dietmar-Hopp-Allee>
expected: <500> but was: <16>
В соответствии с документацией здесь
Утверждает, что все предоставленные исполняемые файлы не вызывают AssertionError.
Если какой-либо поставляемый Исполняемый выдает AssertionError, все остальные исполняемые файлы все равно будут выполнены, и все сбои будут агрегированы и отправлены в MultipleFailuresError. Однако, если исполняемый файл генерирует исключение, которое не является AssertionError, выполнение будет немедленно прекращено, и исключение будет восстановлено как зашитое как исключенное исключение.
Таким образом, основное отличие заключается в том, что assertAll разрешит выполнение всех утверждений без нарушения потока, в то время как другие, подобные assertTrue , и партия остановит тест с помощью AssertionError
Итак, в вашем первом примере оба утверждения будут выполняться независимо от прохода до отказа, а во втором примере тест остановится, если первое утверждение не удастся.
Есть ли какая-либо причина для группировки несколько утверждений
Если вы хотите, чтобы все утверждения выполнялись в модульном тесте.
Address:equalsпроверяет именно эти свойства, и в этом случае я мог бы проверить их с одним утверждением. Логически не было бы никакой разницы, но вдруг это «только одно утверждение». То же самое верно, если я переживаю боль, чтобы создать сокет Hamcrest для класса. – Nicolai 25 November 2016 в 22:46