yoklateknik mülakat
GelişimGeçmiş

Backend Test Mülakat Soruları

75 doğrulanmış Backend Test mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

TestZorluk 1
Bir unit test öncelikle neyi doğrular?
  • aUygulamanın bütününün son kullanıcı gözünden doğru çalıştığını
  • bKüçük, izole bir mantık parçasının kendi başına doğru davrandığını✓
  • cUygulamanın yüksek yük altında yanıt vermeye devam ettiğini
  • dAyrı modüllerin birbiriyle doğru haberleştiğini
Açıklama:Unit test, test edilebilir en küçük mantık parçasını dış bağımlılıklardan izole ederek hedefler. Modüllerin birlikte çalışmasını doğrulamak (d) integration testin, son kullanıcı bakışı (a) ise end-to-end testin işidir.
TestZorluk 1
Test piramidine göre bir projede neden çok sayıda unit test ama az sayıda end-to-end test olmalıdır?
  • aÇünkü end-to-end testler unit testlerden daha az bug bulur
  • bÇünkü CI sunucularının güvenilir şekilde çalıştırabildiği tek tür unit testtir
  • cÇünkü alt seviye testler daha hızlı ve stabildir; toplu çalıştırması ve debug etmesi daha ucuzdur✓
  • dÇünkü unit coverage yükselince integration testlere gerek kalmaz
Açıklama:Piramit, maliyet ve geri bildirim hızıyla ilgilidir: unit testler milisaniyelerde koşar ve hatayı noktasal gösterir; end-to-end testler ise yavaştır, kırılgandır ve çok sayıda olduklarında bakımı pahalıdır. Mesele e2e'nin az bug bulması (a) değildir — kritik akışlar için az sayıda e2e test şarttır.
TestZorluk 2
counter = 0   // modül seviyesinde paylaşılan değişken

test "single increment" {
  increment()
  assert counter == 1
}

test "double increment" {
  increment()
  increment()
  assert counter == 3
}

Dosya baştan sona çalıştığında iki test de geçiyor. Buradaki problem nedir?
  • aTestler mutable state paylaşıyor; tek başına, farklı sırada veya paralel çalıştıklarında kırılırlar✓
  • bHiçbir şey — suite'in tamamı geçtiği sürece testler sağlıklıdır
  • cKodda sorun yok, çünkü test runner'lar her testten önce modül değişkenlerini sıfırlar
  • dİki test aynı mantığı tekrarlıyor; tek bir test halinde birleştirilmeliler
Açıklama:İkinci test 3 beklentisini ancak ilk test paylaşılan counter'ı artırdığı için tutturur; tek başına çalışsa 2 görür ve kırılır. Test runner'lar modül state'ini sihirli biçimde sıfırlamaz (c) — her test kendi başlangıç state'ini kendisi kurmalıdır.
TestZorluk 2
Unit test ile integration test arasındaki temel fark nedir?
  • aUnit test, tek bir fonksiyonu test ettiği sürece gerçek veritabanını serbestçe kullanabilir
  • bIntegration test sistemi her zaman kullanıcı arayüzü üzerinden sürer
  • cUnit testleri developer'lar yazar; integration testler yalnızca QA'in işidir
  • dUnit test tek bir mantık parçasını izole eder; integration test bileşenlerin birlikte çalışmasını doğrular✓
Açıklama:Integration test gerçek iş birliğini çalıştırır — örneğin service kodunu gerçek veritabanına karşı; unit test ise mantığı izole etmek için bu bağımlılıkları test double'larla değiştirir. Gerçek veritabanına dokunan bir test (a) çoğu ekibin sözlüğünde artık integration testtir.
TestZorluk 2
İçeride üçüncü parti bir HTTP döviz kuru API'sini çağıran convertPrice(amount, currency) fonksiyonuna unit test yazıyorsun. Test bu API çağrısını nasıl ele almalı?
  • aTest olabildiğince gerçekçi kalsın diye gerçek API çağrılmalı
  • bAPI client'ı, sabit bir kur döndüren bir test double ile değiştirilmeli✓
  • cDış servise bağımlı olduğu için bu fonksiyonun testi atlanmalı
  • dİlk gerçek API cevabı diske cache'lenip sonraki koşularda tekrar kullanılmalı
Açıklama:Sabit kur döndüren bir double, testi hızlı ve deterministik yapar; belirli senaryoları (örn. belirli bir kur) birebir kurgulamayı sağlar. Gerçek çağrı (a) testi yavaş ve flaky yapar, sonucu canlı veriye bağlar; cache'li varyant (d) yine ilk gerçek çağrıya bağımlıdır ve testin hangi varsayımla çalıştığını gizler.
TestZorluk 2
Birçok test framework'ünde, dosyadaki her testten önce çalışan bir setup bloğu tanımlanabilir (pseudocode: setup { ... }). Bunun amacı nedir?
  • aHer testten önce bilinen, temiz bir başlangıç state'i kurmak✓
  • bHız için ortak veriyi bir kez hazırlayıp tüm testlerde yeniden kullanmak
  • cTestlerin tanımlandıkları sırayla çalışmasını garanti etmek
  • dKırılan bir testi temiz bir state ile otomatik olarak yeniden denemek
Açıklama:Test başına çalışan setup, testleri bağımsız tutar: her test aynı bilinen state'ten başlar. Veriyi bir kez hazırlayıp paylaşmak (b) before-all tarzı bir hook'u tarif eder — pahalı kaynaklar için pratiktir ama paylaşılan veri mutable olduğunda testler arası coupling'in klasik kaynağıdır.

Uzmanlığa göre

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

Kıdeme göre

Backend JuniorBackend MidBackend Senior

Diğer alanlar

FrontendFullstackDevOps / CloudAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

3300 soruluk Backend bankasında kendini sına.

Mülakata başla