Kiedy patrzę na przykłady w klasie Assert JavaDoc

assertThat("Help! Integers don't work", 0, is(1)); // fails:
// failure message:
// Help! Integers don't work
// expected: is <1> 
// got value: <0>
assertThat("Zero is one", 0, is(not(1))) // passes

Dont widzę dużą przewagę nad, powiedzmy assertEquals( 0, 1 ).

Może to fajne dla wiadomości, jeśli konstrukcje stają się bardziej skomplikowane, ale czy widzisz więcej zalet? Czytelność?

Nie ma dużej korzyści w tych przypadkach, w których assertFooistnieje dokładnie zgodne z Twoim zamiarem. W takich przypadkach zachowują się prawie tak samo.

Ale kiedy dojdziesz do nieco bardziej złożonych czeków, korzyść staje się bardziej widoczna:

assertTrue(foo.contains("someValue") && foo.contains("anotherValue"));

vs.

assertThat(foo, hasItems("someValue", "anotherValue"));

Można dyskutować, który z nich jest łatwiejszy do odczytania, ale gdy potwierdzenie się nie powiedzie, otrzymasz dobry komunikat o błędzie assertThat, ale tylko bardzo minimalną ilość informacji assertTrue.

assertThatpowie ci, jakie było twierdzenie i co zamiast tego otrzymałeś. assertTruepowie ci tylko, że dotarłeś falsetam, gdzie się spodziewałeś true.

Informacje o wydaniu JUnit dla wersji 4.4 (tam, gdzie została wprowadzona) podają cztery zalety:

• Bardziej czytelna i łatwiejsza do wpisania: ta składnia pozwala myśleć w kategoriach podmiotu, czasownika, obiektu (twierdzenie „x to 3”), a nie assertEquals , które używa czasownika, obiektu, podmiotu (twierdzenie „równa się 3 x”)
• Kombinacje: każda instrukcja dopasowująca może być negowana ( nie (s) ), łączona ( albo (s). Lub (t) ), mapowana do kolekcji ( każda ) lub używana w kombinacjach niestandardowych ( afterFiveSeconds (s) )
• Czytelne komunikaty o błędach. (...)
• Dopasowane niestandardowe. Wdrażając samodzielnie interfejs Matcher , możesz uzyskać wszystkie powyższe korzyści dla własnych niestandardowych asercji.

Bardziej szczegółowa argumentacja od gościa, który stworzył nową składnię: tutaj .

Zasadniczo w celu zwiększenia czytelności kodu .

Poza hamcrest można również użyć fest twierdzeń . Mają kilka zalet w stosunku do ścięgna podkolanowego, takich jak:

• są one bardziej czytelne
  ( assertEquals(123, actual); // reads "assert equals 123 is actual"vs
  assertThat(actual).isEqualTo(123); // reads "assert that actual is equal to 123")
• są wykrywalne ( możesz sprawić, by autouzupełnianie działało z dowolnym IDE ).

Kilka przykładów

import static org.fest.assertions.api.Assertions.*;

// common assertions
assertThat(yoda).isInstanceOf(Jedi.class);
assertThat(frodo.getName()).isEqualTo("Frodo");
assertThat(frodo).isNotEqualTo(sauron);
assertThat(frodo).isIn(fellowshipOfTheRing);
assertThat(sauron).isNotIn(fellowshipOfTheRing);

// String specific assertions
assertThat(frodo.getName()).startsWith("Fro").endsWith("do")
                           .isEqualToIgnoringCase("frodo");

// collection specific assertions
assertThat(fellowshipOfTheRing).hasSize(9)
                               .contains(frodo, sam)
                               .excludes(sauron);


// map specific assertions (One ring and elves ring bearers initialized before)
assertThat(ringBearers).hasSize(4)
                       .includes(entry(Ring.oneRing, frodo), entry(Ring.nenya, galadriel))
                       .excludes(entry(Ring.oneRing, aragorn));

Aktualizacja z 17 października 2016 r

Fest nie jest już aktywny, zamiast tego użyj AssertJ .

Bardzo podstawowym uzasadnieniem jest to, że trudno jest zepsuć nową składnię.

Załóżmy, że po teście określona wartość foo powinna wynosić 1.

assertEqual(1, foo);

--LUB--

assertThat(foo, is(1));

Przy pierwszym podejściu bardzo łatwo jest zapomnieć o prawidłowej kolejności i wpisać ją od tyłu. Zamiast mówić, że test się nie powiódł, ponieważ oczekiwał 1 i uzyskał 2, komunikat jest odwrócony. Nie stanowi problemu, gdy test zakończy się pomyślnie, ale może prowadzić do nieporozumień, gdy test się nie powiedzie.

W drugiej wersji popełnienie tego błędu jest prawie niemożliwe.

Przykład:

assertThat(5 , allOf(greaterThan(1),lessThan(3)));
//  java.lang.AssertionError:
//  Expected: (a value greater than <1> and a value less than <3>)
//       got: <5>
assertTrue("Number not between 1 and 3!", 1 < 5 && 5 < 3);
//  java.lang.AssertionError: Number not between 1 and 3!

1. możesz sprecyzować swoje testy
2. otrzymasz bardziej szczegółowy wyjątek, jeśli testy zakończą się niepowodzeniem
3. łatwiejszy do odczytania test

btw: możesz też pisać tekst w assertXXX ...

assertThat(frodo.getName()).isEqualTo("Frodo");

Jest zbliżony do języka naturalnego.

Łatwiejszy do odczytania, łatwiejszy do analizy kodu. Programista spędza więcej czasu na analizie kodu niż na pisaniu nowego. Jeśli więc kod będzie łatwy do analizy, programista powinien być bardziej produktywny.

Kod PS powinien być równie dobrze napisaną książką. Kod samodokumentowany.

Istnieją zalety do stwierdzenia, że ​​w porównaniu z assertEquals -
1) bardziej czytelne
2) więcej informacji o niepowodzeniach
3) błędy czasu kompilacji - zamiast błędów czasu wykonania
4) elastyczność przy zapisywaniu warunków testowych
5) przenośny - jeśli używasz hamcrest - możesz użyć jUnit lub TestNG jako podstawową strukturę.