Java için iddia kitaplıkları: AssertJ ve Google Truth

kapanış bildirimi

Bu makale İngilizce olarak da mevcuttur. Teknik yardımla tercüme edildi ve yayınlanmadan önce editoryal olarak gözden geçirildi.

Bir daha gösterme.

Birim testleri yazılım mühendisliğinin temel unsurlarından biridir. Yazılımın işlevsel doğruluğunu sağlar ve olası hataların erken tespit edilmesine yardımcı olurlar. İddialar, testin yürütülmesi sırasında beklenen koşulların karşılanmasını sağlamada merkezi bir rol oynar.

Birim testleri, test çerçevesinin test sırasında uygunluk kontrollerini kullandığına dair iddialar içerir. Basit bir örnek, belirli bir yöntemle döndürülen değerin olup olmadığını kontrol etmektir. true VE. Bir iddia geçerli değilse testin yürütülmesi durdurulur ve başarısız olduğu kabul edilir. Tüm iddialar karşılanırsa test çerçevesi testi sonuna kadar çalıştırır ve başarılı kabul edilir.

Bir birim testi, genellikle test yönteminin sonuna yerleştirilen birden fazla iddiayı içerebilir. Nadir durumlarda, ara test koşullarına uygunluğu sağlamak için iddialar test senaryosunun ortasında kontrol edilebilir.

Test çerçevelerinin iddia API'lerinde boşluklar var

Test çerçevesi API'si genellikle ilgili programlama dilinde iddialarda bulunmak için kullanılır. Örneğin JUnit for Java, iddiaları ifade etmek için basit API'ler sunar.

Genellikle az sayıda iddia içeren basit testler için yeterlidirler ve doğrudan test çerçevesinde bulunabilme avantajına sahiptirler. Bu nedenle yazılım projesine ek bağımlılıklar entegre etmeye gerek yoktur.

Ancak proje daha büyükse ve testler daha karmaşıksa bu API'ler sınırlarına ulaşır. Her şeyden önce okunabilirlik ve anlaşılabilirlik açısından optimize edilmemişlerdir. Daha karmaşık iddialar için geliştiricilerin çok sayıda standart kod yazması gerekir. Ayrıca, hatalı iddialara ilişkin hata mesajları oldukça kısa ve soyuttur ve örneğin bir koleksiyondaki eksik öğelerle ilgili sorun giderme ayrıntılarından yoksundur. Ek olarak, JUnit'in Onaylama API'si genişletilebilir değildir, dolayısıyla etki alanı mantığınıza yönelik onaylamalarla entegre edilemez.

Aşağıdaki listede JUnit Onaylama API'sinin sınırlamalarını gösteren bir örnek gösterilmektedir.

  @Test
  public void testListComparison() {
    List<String> expectedList = Arrays.asList("Apple", "Banana", "Cherry");
    List<String> actualList = Arrays.asList("Apple", "Grape", "Cherry");

    assertEquals(expectedList, actualList, "Die Listen sollten gleich sein");
  }

İlk olarak, dizeleri içeren iki liste oluşturulur. Yöntem çağrısı assertEquals iki listenin aynı olmasını gerektirir. Listeler farklı öğeler içerdiğinden test aşağıdaki mesajla başarısız olur:

Die Listen sollten gleich sein ==> expected: <[Apple, Banana, Cherry]> but was: <[Apple, Grape, Cherry]>

Mesaj, listelerdeki hangi öğelerin farklı olduğunu açıklamıyor. Bu çok basitleştirilmiş örnekte, geliştiricilerin bunu fark etmesi kolay olabilir, ancak pratikte sıklıkla daha karmaşık durumlar ortaya çıkar. Mesajın hangi öğelerin farklı olduğuna ilişkin spesifik bilgiler içermesi yararlı olacaktır. Bu durumda: dizeler Banana VE Grape.

Başka bir ifade, belirli bir öğenin listede tam olarak bir kez göründüğü olabilir. Bu gereksinim doğrudan JUnit API ile uygulanamaz. Geliştiricilerin gerekli kodu kendilerinin yazması gerekir. AssertJ veya Google Truth gibi iddia kitaplıklarında bu tür kısıtlamalar yoktur. İki kitaplığın API'leri okunabilirlik ve anlaşılabilirlik açısından optimize edilmiştir. İfadeleriniz genellikle doğal dil gibi okunur. Özellikle, birden fazla iddia tek bir ifadede birbirine zincirlenebilir, bu da standart kodu azaltır.

İhlal edilen iddialara ilişkin hata mesajları çok daha ayrıntılıdır ve sorun gidermeyi kolaylaştırır. Ayrıca Java'da dizeler, listeler veya istisnalar gibi standart türler için kapsamlı ve özel API'ler de vardır.

AssertJ kapsamlı onaylama API'leri sunar

AssertJ, geniş bir dizi iddia ve faydalı hata mesajı içeren açık kaynaklı bir Java kütüphanesidir. Ana amaç test kodunun okunabilirliğini arttırmaktır. AssertJ Core, AssertJ'nin çekirdeğidir ve Guava gibi kütüphaneler için başka AssertJ modülleri de vardır.

Kütüphane şu şekilde kullanılabilir: org.assertj:assertj-core Maven ve Gradle kullanarak bir Java projesine entegrasyon. Spring Boot'lu bir proje AssertJ sürümünü otomatik olarak yönetir. Gerekirse AssertJ sürümü özelliğe bağlanabilir assertj.version üzerine yaz.

AssertJ, aşağıdakiler de dahil olmak üzere çeşitli standart Java türleri için geniş bir yelpazede farklı onaylama API'leri sunar: String, List VEYA Predicate ve ilkel türler int VEYA char. Bu API'ler her tür için özelleştirilmiştir ve standart kod yazmaktan kaçınmanıza yardımcı olacak yöntemler sağlar. Bir genel bakış şöyledir:

Dize API'si:

• isNotBlank: Dize boş bir dize değil
• contains: Dize bir alt dize içerir
• hasSize: Dizenin belirli bir uzunluğu vardır
• isUpperCase: Dize yalnızca büyük harfler içerir

Liste/Yinelenebilir API'ler:

• contains: Liste öğeleri herhangi bir sırayla içerir
• containsOnly: Liste herhangi bir sırayla yalnızca belirli öğeleri içerir
• containsExactly: Liste yalnızca belirli öğeleri belirli bir sırayla içerir

İddiaların çeşitliliği birçok kullanım durumunu kapsamaktadır.

Geliştiriciler, çağrıldıklarında metinsel bir açıklama sağlayarak iddialara ek anlam bilgisi ekleyebilirler. Taleplerin karşılanmaması durumunda bu da hata mesajının bir parçasıdır. Bu açıklamaların doğrudan standart konsola mı gönderileceğini yoksa kendi mantığınıza göre, örneğin bunları bir dosyaya kaydetmek için açıklama tüketicisi olarak mı tüketileceğini kontrol etmek için bir konfigürasyon kullanabilirsiniz.

Geliştiriciler için giriş noktası, Assertions sınıfı ve içerdiği yöntemlerdir. assertThat(…). mezhep assertThat(…) ifadelerin sezgiselliğine ve okunabilirliğine vurgu yapıldığını göstermektedir. Bu, iddiaların doğal dil gibi okunmasını sağlar. İlk vasiyet assertThat statik içe aktarma olarak bildirildi:

import static org.assertj.core.api.Assertions.assertThat;

Daha sonra bir test yöntemi ekleyebilirsiniz. assertThat(foo). nereye yaz foo iddianın dayandığı değeri veya nesneyi ifade eder. Neye bağlı olarak foo bir tür için, kod tamamlama doğru şekilde yapılandırılmışsa IDE'ler uygun onaylama API'lerini sunar. Örneğin, türünde bir nesneyi iletirsiniz LocalDate konu olarak aşağıdaki gibi tavsiyeler alın hasMonth VEYA isAfter. Bu, aşağıdaki iddia derlemesiyle sonuçlanır:

assertThat(date).isNotNull().hasMonth(Month.of(1)).isAfter(beginDate);

İfade artık doğal dilde şu şekilde okunabilir: “Tarihin boş olmadığından, 1. ayı (Ocak) olduğundan ve başlangıç ​​tarihinin başka bir tarihten sonra olduğundan emin olun.” Zincirleme yöntem çağrıları ortak koddan kaçınır ve okunabilirliği artırır. İddialardan biri başarısız olduğunda sonrakiler artık kontrol edilmez.

Geliştiriciler bir test durdurulmadan önce tüm iddiaların kontrol edilmesini istediklerinde SoftAssertions'ı kullanırlar. Bunu yapmak için bir yazım nesnesi oluştururlar SoftAssertionsdaha sonra istenen onaylama yöntemlerini çağırın ve sonunda bunları çözün assertAll son inceleme. AssertJ daha sonra tüm başarısız iddiaların bir özetini derler. Bu yaklaşım, tüm hatalara doğrudan genel bakış sağladığı ve her hata düzeltmesinden sonra testin yeniden başlatılması zorunluluğunu ortadan kaldırdığı için özellikle karmaşık test senaryoları için uygundur.

Ek olarak AssertJ, uygulama etki alanınıza yönelik iddiaları içerecek şekilde genişletilebilir. Özel iddialar yazmak, veri modelinize dayalı olarak özel iddia yöntemleri geliştirmenize olanak tanır. Randevu yönetimi yazılımı söz konusu olduğunda aşağıdaki iddiaları dikkate alabilirsiniz:

• assertThat(appointment).isDue()
• assertThat(appointment).isCancelled()

Appointment etki alanı modelinizden bir sınıf olacaktır ve isDue birlikte isCancelled bunlar kendi geliştirdikleri onaylama yöntemleri olacaktır. Bu yaklaşım, testlerdeki üretim kodundan uygulama alanınızı yansıtarak birim testlerin okunabilirliğini ve anlaşılabilirliğini artırır. Özel bir iddiayı uygulamak için geliştiricilerin soyut sınıftan yeni bir sınıf oluşturması gerekir. AbstractAssert bir yapıcı ve bir statik türetin assertThatyöntemi ve gerekli tüm iddia yöntemlerini (örneğin isDue, isCancelled vb.) uygulamak.

Google Truth anlaşılır ve net API'lere dayanmaktadır

Java için başka bir iddia kitaplığı, Google'ın Guava ekibi tarafından geliştirilen ve bakımı yapılan Google Truth'tur. Google'ın kod tabanındaki çoğu testte kullanılır. İçeriğin odak noktası okunabilir iddialar ve hata mesajlarıdır. Truth, Guava kütüphanesindeki birçok standart Java türünü ve türünü destekler. Gerçeği Maven veya Gradle projelerine entegre etmek, yapı aracılığıyla yapılır com.google.truth:truth.

Gerçeği bir testte kullanmak için öncelikle yönteme sahip olmanız gerekir. assertThatstatik bir içe aktarma yoluyla sağlanır:

import static com.google.common.truth.Truth.assertThat;

AssertJ'ye benzer şekilde, bir nesne argüman olarak kullanılabilir assertThat iletildi; bu, bağımsız değişken türüne karşılık gelen iddia API'leriyle sonuçlanır. Truth belgelerinden basit bir örnek, bir dizenin belirli bir alt dizeyle başlayıp başlamadığını kontrol etmektir:

String string = "awesome";
assertThat(string).startsWith("awe");

İhlal edilen iddialara ilişkin hata mesajlarına daha fazla anlam kazandırmak için geliştiriciler uygun bir açıklama sağlayabilir. Bunu yapmak için yöntemi içe aktarın assertWithMessage ve şunu arayın:

import static com.google.common.truth.Truth.assertWithMessage;

assertWithMessage("Without me, it's just aweso")
    .that(string)
    .contains("me");

Gerçek aynı zamanda kendi kişiselleştirilmiş onaylamalarınızla genişlemenize de olanak tanır. Gerçek veri modelinde bunun için özel nesnenizi yazın. Sınıf Nesneniz sınıfa ait olmalıdır Subject türetilmiş olsun. Ayrıca statik bir yardımcı yönteme ve bir yapıcıya ihtiyacı vardır. Ayrıca, belirli iddia yöntemlerinin eklenmesi gerekir. Truth belgeleri, EmployeeSubject referans örneğine işaret eder.

Tüm iddiaların tam olarak kontrol edilmesinin yararlı olduğu birçok iddialı büyük testler için sınıf Truth ile gelir. Expect kullanım için, bir JUnit kural açıklaması aracılığıyla başlatıldı:

@Rule public final Expect expect = Expect.create();

Nesne üzerinde Expect o zaman şöyle bir şey yapabilirsin assertThat Bir argüman belirtin ve uygun iddialarda bulunun. Maalesef bu yaklaşımın yalnızca JUnit 4'e kadar desteklendiği ortaya çıktı. JUnit 5'ten itibaren kural açıklaması artık mümkün değil ve Truth henüz alternatif bir uygulama sunmuyor (Nisan 2026 itibarıyla). JUnit 6 Eylül 2025'te piyasaya sürüldüğünden JUnit 4'ün kullanılması önerilmez. Bu nedenle yapabilirsiniz Expect artık kullanışlı değil.