[ARAÇ] SDL3 Birim Testler

Evet, sevgili yazılımperver dostlarım son yazılarımla birlikte artık SDL3 uygulamalarınızı oluşturmaya başladığınızı düşünüyorum. Bu yazılar ile birlikte, SDL3 giriş yapmış ve yazılım tasarım örüntülerini de kullandığımız temel bir örnek oluşturmuştuk.

[ARAÇ] SDL3 İlk Adımlar – I

[ARAÇ] SDL3 İlk Adımlar – II

Bu yazımızda ise, yazılım geliştirme sürecinin önemli bir parçası olan birim testlere eğilerek, en son geliştirdiğimiz uygulama için gerekli birim testleri (tabi ki yapay zeka yardımı ile 🙂 ) oluşturarak projemize ekliyor olacağız. Bunu yaparken nelere dikkat etmemiz gerektiğine, cmake’i nasıl kullanacağımıza ve ilgili test projesini nasıl oluşturacağımıza bakacağız.

Yazılım geliştirme hayatınız boyunca, vazgeçmememiz gereken (elbette istisnalar olabilir) en önemli hususlardan birisi de birim testlerdir. Birim testler, geliştirdiğiniz yazılımlarınızın gürbüzlüğü için ilk satıhtır. Bu testler ile ilk etapta temel kabiliyetleri doğrular sonrasında ise her değişiklikte yazılımın bütünlüğünün korunduğunu garanti altına almamıza yardımcı olur.

Birim testler geliştirilirken düşülen ikilemlerden birisi de, bunlara gerçekten vakit ayırmalı mıyızdır? Bazen bunlar vakit kaybı olarak da görünse de (ilk etapta elbette alt yapının ayağa kaldırılması ve birim testlerin yazılması için biraz emek gerekiyor), sonrasında bunun sizlere dönüşü ve kazancı çok daha büyük olacaktır. Neyse bu yazımızın amacı birim testler değil ama kısaca birim testlerin faydalarını sıralayıp, meraklı okuyucularımı daha önce bu minvalde kaleme aldığım yazılara yönlendiriyorum. Birim testlerin faydalarını kısaca sıralayacak olursak:

Kodun modülerize edilmesine, daha kolay test edilebilir parçalara ayrılmasına yardımcı olur,
Hatalar daha kolay ve hızlı bir şekilde bulmanıza olanak sağlar,
Her birim tarafından sunulan işlevsellik daha iyi anlaşılır,
Yazılımın hayat döngüsünde ileri zamanlarda yapılacak güncellemelerin doğru bir şekilde yapıldığından emin olunur (alt seviye regresyon testleri olarak düşünebilirsiniz),
Zaman kazandırır ve maliyeti düşürür.

Daha önce bu konuya değindiğim yazılara da aşağıdan ulaşabilirsiniz:

Birim Test Tavsiyeleri

Uygulama İzleme Yazılımı 3 – Utility, Birim Testler, Sürekli Entegrasyon

uEngine4 – GitHub Actions

Evet gelelim SDL3 örneğimize. Biz örneğimizde google test ve mock kullanıyor olacağız. Bu kütüphanelerin nasıl kullanılacağına da burada değinmeyeceğim, yukarıdaki yazılarda bunlara değindim.

Birim testler genel olarak kodlarımız ile birlikte yaşarlar ve dizin olarak da onlara yakın olurlar. Biz de benzer bir yaklaşım izleyeceğiz (aslına bakarsanız C++ şablon repomuzda da bu şekilde 🙂 ). Ana dizin altında bulunan “/test” dizini içerisinde ilgili test kodlarımız bulunuyor olacak.

Testleri yazdırmak için ise VsCode ile GitHub CoPilot’u kullanacağım. Belki ayrı bir yazıda, VsCode içerisinden, CoPilot’ı nasıl kullanacağımıza da değinebiliriz. Muhtemelen ürettiği kodlara ufak dokunuşlar yapmak gerekecektir ama bu aşamada sunacağı testlerin yeterli olacağını düşünüyorum.

İlk olarak ana proje dizininde bulunan cmake betiğine test dizinini ekliyoruz:

if(BUILD_TESTING)
    add_subdirectory(test) 
endif()

if(BUILD_TESTING)

add_subdirectory(test)

endif()

Bundan sonra uygulama kodlarımızı birim testlere nasıl dahil edeceğimize sıra geldi. Bunun için farklı yöntemler mevcut, biz burada genel kabul gören, ilgili kod parçalarını statik kütüphane haline getirip daha sonra bunu ilgili test projesinde bağlama yaklaşımını tercih edeceğiz.

Peki başka nasıl yapabiliriz? İlgili kod parçalarını ilgili test projesine ayrı ayrı ekleyebiliriz. Küçük projeler için bu olabilir ama projeniz büyüdükçe bu zor olacaktır.

CMake kullandığımız için statik kütüphane oluşturmak bizim için çok da sıkıntı olmayacak sadece aşağıdaki satırı eklememiz yeterli olacak. İlgili cmake betik dosyasını incelediğinizde, ana uygulama projesine de artık, kaynak kodları tek tek eklemiyor, yeni eklediğimiz statik kütüphane target’ını bağlıyoruz.

set(TARGET_UNIT_TEST_LIB ${TARGET_NAME}-lib)
add_library(${TARGET_UNIT_TEST_LIB} "")
target_sources(${TARGET_UNIT_TEST_LIB} PRIVATE
    src/components.cpp
    src/event-system.cpp
    src/render-strategies.cpp
    src/renderer.cpp
    src/sdl-application.cpp
    src/graphical-object-factory.cpp
)

target_link_libraries(${TARGET_NAME}
    PRIVATE SDL3::SDL3 ${TARGET_UNIT_TEST_LIB}
)

set(TARGET_UNIT_TEST_LIB ${TARGET_NAME}-lib)

add_library(${TARGET_UNIT_TEST_LIB} "")

target_sources(${TARGET_UNIT_TEST_LIB} PRIVATE

src/components.cpp

src/event-system.cpp

src/render-strategies.cpp

src/renderer.cpp

src/sdl-application.cpp

src/graphical-object-factory.cpp

)

target_link_libraries(${TARGET_NAME}

PRIVATE SDL3::SDL3 ${TARGET_UNIT_TEST_LIB}

)

Bir sonraki adım, test projemiz için kullanacağımız google test kütüphanesinin ilgili birim test projesine dahil edilmesi olacak. Bunun için aşağıdaki güncellemeleri yapacağız cmake içerisinde. Bu satırlar ile cmake üzerinden, konfigürasyon zamanında ilgili kütüphaneyi indirerek derlemekte ve kullanımınıza sunmakta.

include(FetchContent)

FetchContent_Declare(
    googletest
    URL https://github.com/google/googletest/archive/refs/tags/v1.13.0.zip
)
FetchContent_MakeAvailable(googletest)

...

# Testleri aktiflestirelim
enable_testing()

target_link_libraries(${TEST_TARGET_NAME} 
    GTest::gtest_main 
    sdl3-example-app-lib
)

include(GoogleTest)
gtest_discover_tests(${TEST_TARGET_NAME})

include(FetchContent)

FetchContent_Declare(

googletest

URL https://github.com/google/googletest/archive/refs/tags/v1.13.0.zip

)

FetchContent_MakeAvailable(googletest)

...

# Testleri aktiflestirelim

enable_testing()

target_link_libraries(${TEST_TARGET_NAME}

GTest::gtest_main

sdl3-example-app-lib

)

include(GoogleTest)

gtest_discover_tests(${TEST_TARGET_NAME})

Bu ayarlamaları da yaptıktan sonra sıra geldi birim testlerimize. Bu yazımız için, birim testleri, asıl kaynak kodları yazdıktan sonra yazıyoruz ama bu açıkçası, yazı dizisinin anlam bütünlüğünü korumak için. Normal şartlarda, kendi yazılımınızı geliştirirken, sınıflarınız için birim testleri peyder pey yazıyor olmanızda fayda var. Her eklenen public fonksiyon için birim testlerinizi yazmaya başlayabilirsiniz.

Şimdi konumuza geri dönelim ve SDLResource sınıfımızdan başlayarak birim test yazmaya başlayalım dilerseniz. Bu sınıfımız bir önceki yazımızda RAII prensibine göre SDL kaynaklarının jenerik bir şekilde yönetilmesi için kullanabileceğiniz bir sınıf.

Bu sınıf için birim testleri üretmek için, SDLResource sınıfına giderek, ilgili kod parçasını seçip, copilot’a birim test üret dediğimizde muhtemelen sdl_resource_test.cpp deki gibi bir kod üretiliyor olacak. Burada, ilk değineceğimiz konu, birim test dosya isimlendirmesi. Herşeyde olduğu gibi burada bir standart izlemekte fayda var ve biz uygulamalarımızda “sınıf-ismi-test.cpp” isimlendirmesini takip ediyor olacağız.

Üretilen testlere yönelik değineceğim ikinci konu ise, birim testlerin isimlendirilmesi. Burada, açıkçası testlerin ne yapması gerektiğine odaklanarak, testin ne yapmayı hedeflediğini ifade edecek bir isimlendirme yapmayı tercih ediyorum. Bu bazen uzun olabiliyor, bununla birlikte birim testler için bunun bir problem teşkil etmediğini düşünüyorum. Elbette burada, birden fazla “and”‘ler ile bir şeyleri test edip/doğrulamaktan kaçınmakta fayda var.

Aşağıda, benim ürettiğim testleri görebilirsiniz:

#include <gtest/gtest.h>
#include <sdl-resource.h>

// Sahte kaynak ve silici (deleter) fonksiyon
struct MockResource {
    int value;
};

static int delete_call_count = 0;
void MockDeleter(MockResource* resource) {
    if (resource) {
        ++delete_call_count;
        delete resource;
    }
}

using Resource = SDLResource<MockResource, MockDeleter>;

class SDLResourceTest : public ::testing::Test {
protected:
    void SetUp() override {
        delete_call_count = 0;
    }
};

TEST_F(SDLResourceTest, ConstructorShouldStoreGivenResource) {
    auto* raw = new MockResource{42};
    Resource res(raw);
    EXPECT_EQ(res.Get(), raw);
    EXPECT_TRUE(res.IsValid());
}

TEST_F(SDLResourceTest, DestructorShouldCallDeleterWhenResourceIsValid) {
    {
        auto* raw = new MockResource{42};
        Resource res(raw);
    }
    EXPECT_EQ(delete_call_count, 1);
}


TEST_F(SDLResourceTest, DestructorShouldNotCallDeleterWhenResourceIsNull) {
    {
        Resource res(nullptr);
    }
    EXPECT_EQ(delete_call_count, 0);
}

TEST_F(SDLResourceTest, MoveConstructorShouldTransferOwnership) {
    auto* raw = new MockResource{42};
    Resource res1(raw);
    Resource res2(std::move(res1));

    EXPECT_EQ(res2.Get(), raw);
    EXPECT_FALSE(res1.IsValid());
    EXPECT_TRUE(res2.IsValid());
}

TEST_F(SDLResourceTest, MoveAssignmentShouldTransferOwnershipAndCallDeleterOnOldResource) {
    auto* raw1 = new MockResource{1};
    auto* raw2 = new MockResource{2};

    Resource res1(raw1);
    Resource res2(raw2);

    res2 = std::move(res1);

    EXPECT_EQ(res2.Get(), raw1);
    EXPECT_FALSE(res1.IsValid());
    EXPECT_TRUE(res2.IsValid());
    EXPECT_EQ(delete_call_count, 1); // raw2 silinmiş olmalı
}

TEST_F(SDLResourceTest, MoveAssignmentShouldHandleSelfAssignmentGracefully) {
    auto* raw = new MockResource{42};
    Resource res(raw);
    res = std::move(res); // kendi kendine move

    EXPECT_EQ(res.Get(), raw); // kaynak kaybolmamalı
    EXPECT_TRUE(res.IsValid());
    EXPECT_EQ(delete_call_count, 0);
}

TEST_F(SDLResourceTest, ReleaseShouldReturnAndClearInternalPointer) {
    auto* raw = new MockResource{123};
    Resource res(raw);

    auto* released = res.Release();

    EXPECT_EQ(released, raw);
    EXPECT_FALSE(res.IsValid());

    // Manuel silmek gerekir çünkü artık RAII dışı
    MockDeleter(released);
    EXPECT_EQ(delete_call_count, 1);
}

TEST_F(SDLResourceTest, BoolConversionShouldReflectValidity) {
    Resource valid(new MockResource{});
    Resource invalid(nullptr);

    EXPECT_TRUE(valid);
    EXPECT_FALSE(invalid);
}

100

101

102

103

104

#include <gtest/gtest.h>

#include <sdl-resource.h>

// Sahte kaynak ve silici (deleter) fonksiyon

struct MockResource {

int value;

};

static int delete_call_count = 0;

void MockDeleter(MockResource* resource) {

if (resource) {

++delete_call_count;

delete resource;

}

using Resource = SDLResource<MockResource, MockDeleter>;

class SDLResourceTest : public ::testing::Test {

protected:

void SetUp() override {

delete_call_count = 0;

}

};

TEST_F(SDLResourceTest, ConstructorShouldStoreGivenResource) {

auto* raw = new MockResource{42};

Resource res(raw);

EXPECT_EQ(res.Get(), raw);

EXPECT_TRUE(res.IsValid());

}

TEST_F(SDLResourceTest, DestructorShouldCallDeleterWhenResourceIsValid) {

{

auto* raw = new MockResource{42};

Resource res(raw);

}

EXPECT_EQ(delete_call_count, 1);

}

TEST_F(SDLResourceTest, DestructorShouldNotCallDeleterWhenResourceIsNull) {

{

Resource res(nullptr);

}

EXPECT_EQ(delete_call_count, 0);

}

TEST_F(SDLResourceTest, MoveConstructorShouldTransferOwnership) {

auto* raw = new MockResource{42};

Resource res1(raw);

Resource res2(std::move(res1));

EXPECT_EQ(res2.Get(), raw);

EXPECT_FALSE(res1.IsValid());

EXPECT_TRUE(res2.IsValid());

}

TEST_F(SDLResourceTest, MoveAssignmentShouldTransferOwnershipAndCallDeleterOnOldResource) {

auto* raw1 = new MockResource{1};

auto* raw2 = new MockResource{2};

Resource res1(raw1);

Resource res2(raw2);

res2 = std::move(res1);

EXPECT_EQ(res2.Get(), raw1);

EXPECT_FALSE(res1.IsValid());

EXPECT_TRUE(res2.IsValid());

EXPECT_EQ(delete_call_count, 1); // raw2 silinmiş olmalı

}

TEST_F(SDLResourceTest, MoveAssignmentShouldHandleSelfAssignmentGracefully) {

auto* raw = new MockResource{42};

Resource res(raw);

res = std::move(res); // kendi kendine move

EXPECT_EQ(res.Get(), raw); // kaynak kaybolmamalı

EXPECT_TRUE(res.IsValid());

EXPECT_EQ(delete_call_count, 0);

}

TEST_F(SDLResourceTest, ReleaseShouldReturnAndClearInternalPointer) {

auto* raw = new MockResource{123};

Resource res(raw);

auto* released = res.Release();

EXPECT_EQ(released, raw);

EXPECT_FALSE(res.IsValid());

// Manuel silmek gerekir çünkü artık RAII dışı

MockDeleter(released);

EXPECT_EQ(delete_call_count, 1);

}

TEST_F(SDLResourceTest, BoolConversionShouldReflectValidity) {

Resource valid(new MockResource{});

Resource invalid(nullptr);

EXPECT_TRUE(valid);

EXPECT_FALSE(invalid);

}

Sınıfımız için gerekli birim testleri yazdıktan sonra gelelim üçüncü konuya. Birim test yazdık güzel de, bu testler geliştirdiğimiz kodların yüzde kaçını içeriyor. İşte buna birim test kapsama oranı diyoruz (uınit test coverage). Bunun ölçümü, birim testlerin koşturularak, buradan çağrılan fonksiyonları analiz edip hangi satırların çalıştırıldığı temeline dayanmakta (şimdi gidip ben elle bütün API’leri çağırsam, kapsama oranı %100 olmaz mı diye sorabilirsiniz, elbette olur ama bu da kendimizi kandırmaktan başka bir işe yaramaz öyle değil mi:) ).

Bu iş için de yine bir çok hazır araç bulunmakta. Ben burada linux için gcov + lcov ile gcovr‘u kullanacağım. Gcov, kapsama analizi verilerini üretiyor, lcov ile gcovr ise bunları kullanarak raporlama yapıyor. Windows için ise opencppcoverage aracı da oldukça kullanışlı bir araç.

Öncelikle bu araçları yüklememiz gerekiyor. Aşağıdaki satırlar ile bunları kurabilirsiniz:

sudo apt install lcov gcovr

1	sudo apt install lcov gcovr

Daha sonra, test projesinin cmake betiği içerisine aşağıdaki satırları ekliyorsunuz. Bu sayede derleyici, yazılım oluşturma aşamasında gerekli eklemeleri yapıyor.

target_compile_options(SDLResourceTest PRIVATE --coverage)
target_link_options(SDLResourceTest PRIVATE --coverage)

1 2	target_compile_options(SDLResourceTest PRIVATE --coverage) target_link_options(SDLResourceTest PRIVATE --coverage)

Daha sonra build dizinini silip, test uygulamamızı baştan derleyelim. Sonra da testleri koşturalım ve aşağıdaki komutları çağıralım:

lcov --capture --directory . --output-file coverage.info      
lcov --remove coverage.info '*test*' '/usr/*' --output-file coverage_filtered.info
genhtml coverage_filtered.info --output-directory coverage_report

lcov --capture --directory . --output-file coverage.info

lcov --remove coverage.info '*test*' '/usr/*' --output-file coverage_filtered.info

genhtml coverage_filtered.info --output-directory coverage_report

Yukarıdaki komutları /scripts dizini altındaki generate_coverage.sh betiği ile de çağırabilirsiniz.

Komutlar sonrasında /coverage_report/index.html ile kodunuzun ne kadarının testler ile kontrol edildiğini görüntüleyebilirsiniz. Benim çağırdığım koşum için görüntü aşağıdaki gibi:

Yukarıdakine benzer şekilde gcovr ile de raporlama almak için aşağıdaki komutları kullanabilirsiniz:

mkdir gcovr_report
gcovr -r .. --html --html-details -o gcovr_report/coverage.html

1 2	mkdir gcovr_report gcovr -r .. --html --html-details -o gcovr_report/coverage.html

Umarım birim testler, bunların kullanımı ve neye hizmet ettiği konusuna yönelik kafanızda bir soru işareti kalmamıştır.

Güncel repoya aşağıdaki adresten ulaşabilirsiniz.

https://github.com/yazilimperver/cpp-playground

Bir sonraki yazımda, birim testleri de koşturduktan sonra yine yazılım geliştirmenin önemli bir parçası olan ve daha önce bir çok yazımda da bahsettiğim CI/CD adımlarına göz atıyor olacağız. O yazıma kadar kendinize iyi bakın, serin kalın 🙂

Paylaşmak güzeldir.

Kaynaklar

Bir yanıt yazın Yanıtı iptal et