İnşaat yazılımının geliştirilmesi giderek karmaşıklaşıyor. Daha güçlü mikrodenetleyiciler, daha yüksek ağlar ve güvenlik ve güvenilirlik talepleri sayesinde, karmaşıklıklarındaki ürün yazılımı projeleri genellikle PC'deki klasik yazılım projelerinden farklı değildir. Bununla birlikte, dahil edilen uygulamalar için çerçevenin özel koşulları geçerlidir: titiz kaynakların sınırları, acil donanım bağımlılıkları, gerçek zamanlı gereksinimler ve çok erken geliştirme aşamalarında hata yapmadan istikrarlı bir sistem tasarlanması gerekir.
Klaus Roodewig, Bilgi Teknolojisi Federal Ofisi'nin Siber Güvenlik Uzman Çemberinin bir üyesidir ve şirketi ile uygulamalar ve diğer yazılımlar geliştirir.
Bu noktada, testler (Test Odaklı Geliştirme, TDD) liderliğindeki gelişme yardımcı olabilir. TDD, gerçek işlevselliği uygulamadan önce kasıtlı olarak test yazımı sunan bir profesyonel gelişim uzmanıdır. Temel fikir: Test daha önce formüle edilirse, kodun daha sonra ne yapması gerektiğini tam olarak bilirsiniz. Bu test başarısız olur (kırmızı faz), test geçişini gerçekleştirmek için minimal gerekli kod (yeşil faz) uygulanır. Ardından kodu geliştirin ve temizleyin (Refactor aşaması). Bu döngü hala gerçekleştiriliyor. Sonuç olarak, daha güvenli görünen ve daha az hataya sahip olan temiz, anlaşılabilir ve iyi test edilmiş modüller oluşturulur.
Daha önce kafa, sonra uygulayın
TDD, testin gerçek koddan önce yazıldığı çevik yazılım geliştirme ortamından bir teknolojidir. İlk başta çelişkili görünüyor: henüz var olmayan bir şeyi nasıl test edebilirsiniz? Bu tam olarak TDD'nin gücüdür: test, belirli bir işlevsellik olarak gereksinimlerin bir tanımı olarak hareket eder. İlk test, işlevin nasıl davranması gerektiğini açıklar. Mantıksal olarak, işlev henüz uygulanmadığı için bu test başarısız olur. Bu kırmızı faz.
Ardından, test geçişini çalıştırmak için minimum kodu yazın. Bu aşamaya yeşil faz denir. Test yeşil olur olmaz (yani geçer), geliştiricilerin kodu geliştirdiği, basitleştirmesi ve optimize ettiği refactor aşaması başlar. Testler, işlevselliğin değişmeden kalmasını sağlar.
Bu döngü-kırmızı-yeşil-kira defalarca ve tekrar tekrar. Sonuç: Kod herhangi bir zamanda test edilmesi ile kapsanır, gereksinimler net ve anlaşılabilir ve geliştirme ekibi yazılımın kalitesine güven kazanır. Bu paha biçilmez değer güveni, özellikle kraliyet donanımı üzerindeki hata ayıklamanın genellikle karmaşık veya geç olduğu kurulmuş ortamda özellikle karmaşık veya geçdir.
Testlerin geliştirilmesi aşağıdaki avantajları sunar:
Masaüstü veya web uygulamalarından farklı olarak, üretilen yazılım genellikle özel donanımla ilişkilidir. Bir sensör, bir aktüatör veya belirli bir çevresel kayıt, bir fonksiyonun doğru çalışıp çalışmadığını belirler. Bu, test etmeyi zorlaştırır, çünkü bir gppio piminin sorgusunun PC'de kod olarak gerçekleştirilmesi o kadar kolay değildir.
TDD'nin önemli bir uygulaması devreye giriyor: soyutlama ve alaycı. Donanım kayıtlarına doğrudan erişmek yerine, arayüzler tanımlanır. Üretim için, bu arayüz kraliyet donanımına girer ve test ortamında bir simüle veya saplama donanımın yerini alır. Çevredeki ortam simüle edildiğinden, aynı kod PC üzerinde testte gerçekleştirilebilir. Sonuç olarak, önceden ve hedef cihazdan bağımsız olarak birçok hata bulunabilir.
Birleştirilen sistemlerin genellikle çok az RAM ve flaş belleği vardır. Büyük bir test çerçevesi doğrudan hedef sistemde gerçekleştirilemez, ancak ana bilgisayar olarak bir PC gerektirir. Testlerdeki yürütme kodu o kadar soyuttur ki, hem PC'de hem de (teorik olarak) hedefte gerçekleştirilebilir. Bu, mantık ve algoritmaların büyük bölümlerinin, hata ayıklayıcısından bile önceden ve rahatça kontrol edilmesini sağlar.
Gerçek zaman gereksinimleri ve süreleri diğer yönlerdir: birçok dahil edilen işlev zaman süreçlerine bağlıdır. TDD ayrıca burada yardımcı olur: Deterministik testler yapmak için zamanlayıcı ve zamansal fonksiyonlar karşılanabilir.
Karşılaştırma GOOGLE TEST (GTTE) ve CPPutest
Bu makalede bu makalede iki farklı test çerçevesi kullanılmıştır: Google Test ve CPPutest. Her ikisi de, özellikle ana bilgisayar testlerini gerçekleştirerek Incorporated yazılım testleri tarafından yönetilen geliştirmeyi etkinleştirir. Ancak, çerçevenin arkasında çeşitli hedefler ve tasarım felsefeleri vardır.
Google Testi (GTTE), başlangıçta masaüstü ve sunucu uygulamaları için tasarlanmış C ++ tabanlı üniter bir test çerçevesidir. Son derece güçlü ama aynı zamanda karmaşık bir şekilde sunuyor. İfadeler çok sayıda ve granüldür (ör. EXPECT_EQ,, EXPECT_NEAR,, ASSERT_THAT Eşleştirme ile) ve testler (ölüm testleri), parametreli testler, test dosyaları, hazırlıklar ve çok daha fazlası için mekanizmalar vardır.
Başlangıçta, GTET esas olarak C ++ geliştiricilerine yöneliktir. C genellikle dahil edilen projeler için kullanıldığından, C-kaynak kodunu C ++ test sürücüsü aracılığıyla entegre etmek zorunda kalırsınız. Bu temel bir sorun değil, ek bir çaba, çünkü C-başlayıcısı extern "C"-Blöcken dahil olmalıdır. Buna ek olarak, GTET genellikle bir C ++ standart kütüphanesi ve daha modern bir derleyici gerektirir. Her ikisi de kurulmuş hedeflerde mevcut olmadığından, GTTE çoğu durumda yalnızca ana bilgisayarda çalışır.
Projeye entegrasyon
GTTE'nin bir projeye entegrasyonu üç şekilde gerçekleşebilir:
İdeal olarak, CMKelist'teki test dizinleri ve GTTET kitapçısı ayrıldığı bir CMake yapısı ile çalışın. Aşağıdaki kod tipik bir prosedür göstermektedir:
FetchContent_Declare(
googletest
URL https://github.com/google/googletest/archive/refs/tags/release-1.12.1.zip
)
FetchContent_MakeAvailable(googletest)
add_executable(tests test_led.cpp test_sha.cpp)
target_link_libraries(tests gtest_main)
Donanım arayüzlerini simüle etmek için GTTE'nin bir parçası olan Buffardo Framework Gmock'u kullanmak istiyorsanız, Gmococ-SPECT sınıfları ve sanal yöntemler için uygun bir modülde test edilecek işlevleri getirmeniz gerekir. Bu, poz fonksiyonları için daha fazla çaba anlamına gelebilir.
GTTE, Jenkins veya GitLab CI gibi sistemlere entegrasyonu basitleştiren JUNIT formatında testler yapabilir.
GTET için en iyi uygulama ve engeller
Sabit pratiktir, ancak bunları ekonomik olarak kullanmalı ve aşırı karmaşık hale getirmemelisiniz. Basit konfigürasyon/sökme yöntemleri ve izole edilmiş testler olası bir genel bakışa devam etmeye yardımcı olur.
Parametreli testler, farklı test taşıyıcılarına sahip kriptografik işlevler gibi birçok giriş verisinden algoritmaları kontrol etmek için harika.
Doğrudan cihazda test yapması gereken düşük kaynak hedefleri söz konusu olduğunda, GTET nadiren ilk tercihtir. Genişletilir ve çalışma zamanı C ++ işlevlerini gerektirir.
Aşırı mühendisliğe dikkat edin: GTTE ile son derece karmaşık test hiyerarşileri oluşturma riski vardır. Bu, kolay ve hızlı test edilmesi gereken dahil edilmiş modüller için verimsiz olabilir.
Cpputest ile İnce Testler
CPUPUTEST, C ve C ++ için, özellikle inşa edilmiş geliştirmede popüler olan ince bir test çerçevesidir. Minimum bağımlılıklarla sağlanır, kapsamlı bir standart kütüphane gerektirmez ve entegrasyon şekilli araç zincirine getirilmesi daha kolaydır. İfadeler daha kolaydır (ör. CHECK_TRUE,, LONGS_EQUAL,, STRCMP_EQUAL), ancak çoğu uygulama için yeterince esnek. Cpputest kasıtlı olarak minimalist korunur.
Diğer bir avantaj, C fonksiyonları için kullanımı kolay bir alay çerçevesi olan Cppomock ile yakın entegrasyondur. Bu, özellikle donanıma erişimin temel olduğu kurulmuş gelişmede yararlı olduğunu kanıtlamaktadır. Gibi Aramalarla mock().expectOneCall("ReadAdc").andReturnValue(123); Karmaşık bir zarf yazmak zorunda kalmadan işlevleri simüle edebilirsiniz.
Cpputest'i projeye entegre edin
CPPutest genellikle CPPutest deposunun indirilmesi veya klonlanmasıyla entegre edilir. En iyi uygulama gibi, cpputest'i aşağıda -modulus veya statik kütüphane gibi bir projeye eklemek.
Cpputest CMake ile çalışır. Takımlar CPUPPUT kaynak kodunu projelerine ve ardından onunla birlikte taşıyabilir. add_subdirectory(cpputest) entegre. Aşağıdaki kod ayrıca test tablolarında sola doğru yol açar:
add_subdirectory(cpputest)
add_executable(tests test_led.cpp test_sha.cpp)
target_link_libraries(tests CppUTest CppUTestExt)
Özel bir araç zincirinde, örneğin birleştirilmiş bir Linux yıldızı veya hatta doğrudan mikrodenetleyici üzerinde test etmek istiyorsanız, CPPutest'i çapraz araç zinciriyle oluşturmayı deneyebilirsiniz. Ekonomik bağımlılıklar nedeniyle, bu genellikle GTTE'den daha kolay hale getirir.
CPPutest, daha az özel iddialar sağlar, böylece yardımcı işlevleri oldukça karmaşık karşılaştırmalar için gerekli olabilir.
Raporlama ile Cpputest GTTE'nin basittir. Junit'in ilişkileri mümkündür, ancak senaryolarınızı isteyebilirler. Karmaşık raporlama özelliklerine ihtiyaç duyan herkes potansiyel olarak eline yatırım yapmalıdır.
Cppomock, C fonksiyonlarını alevlendirmek için idealdir. Alaycı merkezi bir örnekte çalışır (mock()). Test işlevlerini uygularken, fonksiyonel imzaların tam olarak karşılık geldiğine dikkat edilmelidir. Tökezlenen bir blok bazen çeşitli işlevler veya daha zor olabilecek çizgi işlevleridir.
Cpputest için en iyi uygulama ve engeller
Basit tutun: Tıpkı çerçeve gibi, testler kolay ve anlaşılabilir kalmalıdır.
Alaycı, projedeki donanıma bağlı işlevler olduğunda başlamalıdır. Arayüzleri açıkça tanımlamak önemlidir.
Cppomock, öngörülen çağrıları ve parametreleri tanımlamanıza olanak tanır. Ekipler, kodlarının doğru parametrelerle sağlanan işlevleri hatırlamasını sağlamak için sürekli olarak kullanmalıdır.
Arıza durumunda, CPPutest oldukça basit hata mesajları gösterir. Sorunları, isimleri ve testleri hızlı bir şekilde tanımlamak için açık olmalıdırlar. İfadelerinizden korkmayın: Büyük bayt dizisi veya kriptografik sürümler gibi karmaşık veri yapılarını test etmek zorunda olan herkes, karşılaştırmaların önemli olması için yardım veya iddialar işlevlerini yazmalıdır.
Klaus Roodewig, Bilgi Teknolojisi Federal Ofisi'nin Siber Güvenlik Uzman Çemberinin bir üyesidir ve şirketi ile uygulamalar ve diğer yazılımlar geliştirir.
Bu noktada, testler (Test Odaklı Geliştirme, TDD) liderliğindeki gelişme yardımcı olabilir. TDD, gerçek işlevselliği uygulamadan önce kasıtlı olarak test yazımı sunan bir profesyonel gelişim uzmanıdır. Temel fikir: Test daha önce formüle edilirse, kodun daha sonra ne yapması gerektiğini tam olarak bilirsiniz. Bu test başarısız olur (kırmızı faz), test geçişini gerçekleştirmek için minimal gerekli kod (yeşil faz) uygulanır. Ardından kodu geliştirin ve temizleyin (Refactor aşaması). Bu döngü hala gerçekleştiriliyor. Sonuç olarak, daha güvenli görünen ve daha az hataya sahip olan temiz, anlaşılabilir ve iyi test edilmiş modüller oluşturulur.
Daha önce kafa, sonra uygulayın
TDD, testin gerçek koddan önce yazıldığı çevik yazılım geliştirme ortamından bir teknolojidir. İlk başta çelişkili görünüyor: henüz var olmayan bir şeyi nasıl test edebilirsiniz? Bu tam olarak TDD'nin gücüdür: test, belirli bir işlevsellik olarak gereksinimlerin bir tanımı olarak hareket eder. İlk test, işlevin nasıl davranması gerektiğini açıklar. Mantıksal olarak, işlev henüz uygulanmadığı için bu test başarısız olur. Bu kırmızı faz.
Ardından, test geçişini çalıştırmak için minimum kodu yazın. Bu aşamaya yeşil faz denir. Test yeşil olur olmaz (yani geçer), geliştiricilerin kodu geliştirdiği, basitleştirmesi ve optimize ettiği refactor aşaması başlar. Testler, işlevselliğin değişmeden kalmasını sağlar.
Bu döngü-kırmızı-yeşil-kira defalarca ve tekrar tekrar. Sonuç: Kod herhangi bir zamanda test edilmesi ile kapsanır, gereksinimler net ve anlaşılabilir ve geliştirme ekibi yazılımın kalitesine güven kazanır. Bu paha biçilmez değer güveni, özellikle kraliyet donanımı üzerindeki hata ayıklamanın genellikle karmaşık veya geç olduğu kurulmuş ortamda özellikle karmaşık veya geçdir.
Testlerin geliştirilmesi aşağıdaki avantajları sunar:
- Erken hataların araştırılması: Kodda yayılmadan önce hatalar tespit edilir.
- Yapılandırılmış çalışma: Gereksinimler (testler) açıkça akılda, gerçek hedeflerin ötesinde “programlama” yok.
- Daha iyi bakım: Testler yaşam belgeleri görevi görür. Diğer geliştiriciler (veya birkaç ay sonra kendiniz) daha kolay işlevlerin nasıl planlandığını içerir.
- Daha yüksek kod kalitesi: Yalnızca testler için gerekli kodu yazdığınız için, daha az işe yaramaz ve balastın çözülmesi.
Masaüstü veya web uygulamalarından farklı olarak, üretilen yazılım genellikle özel donanımla ilişkilidir. Bir sensör, bir aktüatör veya belirli bir çevresel kayıt, bir fonksiyonun doğru çalışıp çalışmadığını belirler. Bu, test etmeyi zorlaştırır, çünkü bir gppio piminin sorgusunun PC'de kod olarak gerçekleştirilmesi o kadar kolay değildir.
TDD'nin önemli bir uygulaması devreye giriyor: soyutlama ve alaycı. Donanım kayıtlarına doğrudan erişmek yerine, arayüzler tanımlanır. Üretim için, bu arayüz kraliyet donanımına girer ve test ortamında bir simüle veya saplama donanımın yerini alır. Çevredeki ortam simüle edildiğinden, aynı kod PC üzerinde testte gerçekleştirilebilir. Sonuç olarak, önceden ve hedef cihazdan bağımsız olarak birçok hata bulunabilir.
Birleştirilen sistemlerin genellikle çok az RAM ve flaş belleği vardır. Büyük bir test çerçevesi doğrudan hedef sistemde gerçekleştirilemez, ancak ana bilgisayar olarak bir PC gerektirir. Testlerdeki yürütme kodu o kadar soyuttur ki, hem PC'de hem de (teorik olarak) hedefte gerçekleştirilebilir. Bu, mantık ve algoritmaların büyük bölümlerinin, hata ayıklayıcısından bile önceden ve rahatça kontrol edilmesini sağlar.
Gerçek zaman gereksinimleri ve süreleri diğer yönlerdir: birçok dahil edilen işlev zaman süreçlerine bağlıdır. TDD ayrıca burada yardımcı olur: Deterministik testler yapmak için zamanlayıcı ve zamansal fonksiyonlar karşılanabilir.
Karşılaştırma GOOGLE TEST (GTTE) ve CPPutest
Bu makalede bu makalede iki farklı test çerçevesi kullanılmıştır: Google Test ve CPPutest. Her ikisi de, özellikle ana bilgisayar testlerini gerçekleştirerek Incorporated yazılım testleri tarafından yönetilen geliştirmeyi etkinleştirir. Ancak, çerçevenin arkasında çeşitli hedefler ve tasarım felsefeleri vardır.
Google Testi (GTTE), başlangıçta masaüstü ve sunucu uygulamaları için tasarlanmış C ++ tabanlı üniter bir test çerçevesidir. Son derece güçlü ama aynı zamanda karmaşık bir şekilde sunuyor. İfadeler çok sayıda ve granüldür (ör. EXPECT_EQ,, EXPECT_NEAR,, ASSERT_THAT Eşleştirme ile) ve testler (ölüm testleri), parametreli testler, test dosyaları, hazırlıklar ve çok daha fazlası için mekanizmalar vardır.
Başlangıçta, GTET esas olarak C ++ geliştiricilerine yöneliktir. C genellikle dahil edilen projeler için kullanıldığından, C-kaynak kodunu C ++ test sürücüsü aracılığıyla entegre etmek zorunda kalırsınız. Bu temel bir sorun değil, ek bir çaba, çünkü C-başlayıcısı extern "C"-Blöcken dahil olmalıdır. Buna ek olarak, GTET genellikle bir C ++ standart kütüphanesi ve daha modern bir derleyici gerektirir. Her ikisi de kurulmuş hedeflerde mevcut olmadığından, GTTE çoğu durumda yalnızca ana bilgisayarda çalışır.
Projeye entegrasyon
GTTE'nin bir projeye entegrasyonu üç şekilde gerçekleşebilir:
- Önceden tanımlanmış paketlerin veya paketlerin yönetimi: CMake gibi birçok inşaat sistemi sunmak FetchContent– veya ExternalProject-GTT'yi Github deposundan doğrudan projeye taşıyacak.
- Sistem kurulumu: Linux dağıtımlarında GTTE paketlerini depolardan kurmak genellikle mümkündür. VCPKG veya Conan Windows'ta mevcuttur.
- TESLİM: GTTE deposu bir alt modül olarak deposuna entegre edilebilir.
İdeal olarak, CMKelist'teki test dizinleri ve GTTET kitapçısı ayrıldığı bir CMake yapısı ile çalışın. Aşağıdaki kod tipik bir prosedür göstermektedir:
FetchContent_Declare(
googletest
URL https://github.com/google/googletest/archive/refs/tags/release-1.12.1.zip
)
FetchContent_MakeAvailable(googletest)
add_executable(tests test_led.cpp test_sha.cpp)
target_link_libraries(tests gtest_main)
Donanım arayüzlerini simüle etmek için GTTE'nin bir parçası olan Buffardo Framework Gmock'u kullanmak istiyorsanız, Gmococ-SPECT sınıfları ve sanal yöntemler için uygun bir modülde test edilecek işlevleri getirmeniz gerekir. Bu, poz fonksiyonları için daha fazla çaba anlamına gelebilir.
GTTE, Jenkins veya GitLab CI gibi sistemlere entegrasyonu basitleştiren JUNIT formatında testler yapabilir.
GTET için en iyi uygulama ve engeller
Sabit pratiktir, ancak bunları ekonomik olarak kullanmalı ve aşırı karmaşık hale getirmemelisiniz. Basit konfigürasyon/sökme yöntemleri ve izole edilmiş testler olası bir genel bakışa devam etmeye yardımcı olur.
Parametreli testler, farklı test taşıyıcılarına sahip kriptografik işlevler gibi birçok giriş verisinden algoritmaları kontrol etmek için harika.
Doğrudan cihazda test yapması gereken düşük kaynak hedefleri söz konusu olduğunda, GTET nadiren ilk tercihtir. Genişletilir ve çalışma zamanı C ++ işlevlerini gerektirir.
Aşırı mühendisliğe dikkat edin: GTTE ile son derece karmaşık test hiyerarşileri oluşturma riski vardır. Bu, kolay ve hızlı test edilmesi gereken dahil edilmiş modüller için verimsiz olabilir.
Cpputest ile İnce Testler
CPUPUTEST, C ve C ++ için, özellikle inşa edilmiş geliştirmede popüler olan ince bir test çerçevesidir. Minimum bağımlılıklarla sağlanır, kapsamlı bir standart kütüphane gerektirmez ve entegrasyon şekilli araç zincirine getirilmesi daha kolaydır. İfadeler daha kolaydır (ör. CHECK_TRUE,, LONGS_EQUAL,, STRCMP_EQUAL), ancak çoğu uygulama için yeterince esnek. Cpputest kasıtlı olarak minimalist korunur.
Diğer bir avantaj, C fonksiyonları için kullanımı kolay bir alay çerçevesi olan Cppomock ile yakın entegrasyondur. Bu, özellikle donanıma erişimin temel olduğu kurulmuş gelişmede yararlı olduğunu kanıtlamaktadır. Gibi Aramalarla mock().expectOneCall("ReadAdc").andReturnValue(123); Karmaşık bir zarf yazmak zorunda kalmadan işlevleri simüle edebilirsiniz.
Cpputest'i projeye entegre edin
CPPutest genellikle CPPutest deposunun indirilmesi veya klonlanmasıyla entegre edilir. En iyi uygulama gibi, cpputest'i aşağıda -modulus veya statik kütüphane gibi bir projeye eklemek.
Cpputest CMake ile çalışır. Takımlar CPUPPUT kaynak kodunu projelerine ve ardından onunla birlikte taşıyabilir. add_subdirectory(cpputest) entegre. Aşağıdaki kod ayrıca test tablolarında sola doğru yol açar:
add_subdirectory(cpputest)
add_executable(tests test_led.cpp test_sha.cpp)
target_link_libraries(tests CppUTest CppUTestExt)
Özel bir araç zincirinde, örneğin birleştirilmiş bir Linux yıldızı veya hatta doğrudan mikrodenetleyici üzerinde test etmek istiyorsanız, CPPutest'i çapraz araç zinciriyle oluşturmayı deneyebilirsiniz. Ekonomik bağımlılıklar nedeniyle, bu genellikle GTTE'den daha kolay hale getirir.
CPPutest, daha az özel iddialar sağlar, böylece yardımcı işlevleri oldukça karmaşık karşılaştırmalar için gerekli olabilir.
Raporlama ile Cpputest GTTE'nin basittir. Junit'in ilişkileri mümkündür, ancak senaryolarınızı isteyebilirler. Karmaşık raporlama özelliklerine ihtiyaç duyan herkes potansiyel olarak eline yatırım yapmalıdır.
Cppomock, C fonksiyonlarını alevlendirmek için idealdir. Alaycı merkezi bir örnekte çalışır (mock()). Test işlevlerini uygularken, fonksiyonel imzaların tam olarak karşılık geldiğine dikkat edilmelidir. Tökezlenen bir blok bazen çeşitli işlevler veya daha zor olabilecek çizgi işlevleridir.
Cpputest için en iyi uygulama ve engeller
Basit tutun: Tıpkı çerçeve gibi, testler kolay ve anlaşılabilir kalmalıdır.
Alaycı, projedeki donanıma bağlı işlevler olduğunda başlamalıdır. Arayüzleri açıkça tanımlamak önemlidir.
Cppomock, öngörülen çağrıları ve parametreleri tanımlamanıza olanak tanır. Ekipler, kodlarının doğru parametrelerle sağlanan işlevleri hatırlamasını sağlamak için sürekli olarak kullanmalıdır.
Arıza durumunda, CPPutest oldukça basit hata mesajları gösterir. Sorunları, isimleri ve testleri hızlı bir şekilde tanımlamak için açık olmalıdırlar. İfadelerinizden korkmayın: Büyük bayt dizisi veya kriptografik sürümler gibi karmaşık veri yapılarını test etmek zorunda olan herkes, karşılaştırmaların önemli olması için yardım veya iddialar işlevlerini yazmalıdır.