yoklateknik mülakat
GelişimGeçmiş

Backend Csharp Testing Tooling Mülakat Soruları

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

Gerçek simülasyonu dene →

Örnek sorular

Csharp Testing ToolingZorluk 1
xUnit'te bir metodun test olarak keşfedilip çalıştırılmasını ne belirler?
  • aMetot adı Test ile başlamalıdır; xUnit hâlâ keşif için isimlendirme kuralına dayanır, tıpkı bazı eski test framework'lerinin gerektirdiği gibi
  • bMetot [Fact] (ya da [Theory]) ile işaretlenmelidir; xUnit'in keşif mekanizması bunu tarar✓
  • cMetot, runner'ın instance oluşturmadan çağırabilmesi için public static void olmalıdır
  • dİçinde bulunduğu sınıf, xUnit'in runner'ının başlangıçta aradığı ITestCase arayüzünü implement etmelidir
Açıklama:xUnit testleri tamamen attribute ile keşfeder: parametresiz bir test için [Fact], veri odaklı bir test için [Theory]. İsimlendirme kuralı gerekmez, static şartı yoktur (xUnit her test için bir instance oluşturur) ve implement edilecek bir ITestCase arayüzü de yoktur.
Csharp Testing ToolingZorluk 1
xUnit'te [Fact] ile [Theory] arasındaki temel fark nedir?
  • a[Fact], parametre almayan ve bir kez çalışan bir testi işaretler; [Theory] ise parametre alan ve değerleri sağlamak için [InlineData] gibi bir veri kaynağına ihtiyaç duyan bir testi işaretler✓
  • b[Fact] senkron testler, [Theory] ise async Task testler içindir, bu yüzden aynı test sınıfında ikisini karıştırmak ayrı assertion kütüphaneleri ve ayrı test runner yapılandırması gerektirir
  • c[Theory], eski test runner'larla geriye dönük uyumluluk için tutulan, [Fact]'in kullanımdan kaldırılmış bir takma adıdır
  • d[Fact], sınıftaki tüm [Theory] testlerinden önce çalışır ve veri odaklı testler için bir setup adımı görevi görür
Açıklama:[Fact], tek ve parametresiz bir test durumu içindir. [Theory] ise parametre alan veri odaklı bir test metodu içindir ve bir ya da daha fazla çalıştırma için argüman değerlerini sağlayan en az bir veri kaynağı attribute'üne ([InlineData], [MemberData] ya da [ClassData]) ihtiyaç duyar. İki attribute de senkron/asenkron ile ilgili değildir ve aralarında örtük bir sıralama yoktur.
Csharp Testing ToolingZorluk 2
[Fact]
public void ChecksTotal()
{
    int actualTotal = ComputeTotal(); // 7 döner
    Assert.Equal(actualTotal, 10);
}

Test başarısız oluyor. Hata mesajı ne rapor eder?
  • a"Expected: 7, Actual: 10" — çünkü Assert.Equal'a geçilen ilk argüman expected sayılır ve burada yanlışlıkla önce actualTotal (7) geçilmiştir✓
  • b"Expected: 10, Actual: 7" — çünkü xUnit her zaman küçük sayısal değeri actual olarak etiketler, niyeti argüman pozisyonundan değil değerlerden çıkarır
  • cDerleme hatası oluşur, çünkü Assert.Equal literal expected değerinin ikinci argüman olarak geçilmesini zorunlu kılar
  • d"Expected: 10, Actual: 10" — çünkü xUnit raporlamadan önce iki argümanı da aynı karşılaştırma hedefine indirger
Açıklama:Assert.Equal(expected, actual) sadece pozisyona göre birinci argümanı "expected", ikincisini "actual" sayar. Buradaki çağrı Assert.Equal(actualTotal, 10) olduğundan xUnit actualTotal'ı (7) expected, 10'u actual olarak raporlar. Bu yaygın bir junior hatasıdır — argümanlar ters geçilmiştir, bu testin geçip geçmemesini değiştirmez ama yanıltıcı bir mesaj üretir.
Csharp Testing ToolingZorluk 2
public class MathTests
{
    [Theory]
    [InlineData(2, 4)]
    [InlineData(3, 9)]
    public void SquaresNumber(int input, int expected)
    {
        Assert.Equal(expected, input * input);
    }
}

SquaresNumber kaç kez çalışır ve her [InlineData] ne sağlar?
  • aBir kez çalışır, iki [InlineData] satırı tek bir dizi parametresinde birleştirilerek alınır
  • b4 kez çalışır, çünkü iki [InlineData] attribute'ü iki metot parametresiyle çarpılınca metot gövdesinin dört ayrı çalıştırması ortaya çıkar
  • c2 kez çalışır, her [InlineData] satırı için bir kez; input/expected her seferinde o satırın değerlerine bağlanır✓
  • dDerlenmez, çünkü bir [Theory] metodu yalnızca tek bir [InlineData] attribute'üne sahip olabilir
Açıklama:Her [InlineData(...)] attribute'ü, [Theory] metodunun bir çalıştırması için tam bir argüman seti sağlar. İki [InlineData] attribute'üyle metot iki kez çalışır: bir kez input=2, expected=4 ile, bir kez input=3, expected=9 ile. Bir [Theory] metodunun üzerine istenildiği kadar [InlineData] attribute'ü yığılabilir.
Csharp Testing ToolingZorluk 1
"Test izolasyonu" (her testin diğerlerinden bağımsız olması) neden temel bir test prensibi sayılır?
  • aİzolasyon esasen bir performans optimizasyonudur — izole testler, her bir test metodu arasında runtime'ın class loading ve assembly çözümlemesini atlayabilmesi sayesinde sadece daha hızlı çalışır
  • bİzolasyon, her testin mock yerine gerçek veritabanı ve gerçek network çağrıları kullanması gerektiği, böylece bütün sistemin birlikte çalıştığının kanıtlanması demektir
  • cİzolasyon sadece integration testler için geçerlidir; unit testler paylaşılan kaynaklara asla dokunmadığı için bu prensipten muaftır
  • dİzole bir testin sonucu yalnızca kendi setup'ına ve test edilen koda bağlıdır, bu yüzden tek başına, herhangi bir sırayla ya da paralel çalıştırıldığında da güvenilir sonuç verir✓
Açıklama:Test izolasyonu, bir testin sonucunun çalıştırma sırasına, önce başka testlerin çalışmış olmasına ya da artakalan paylaşılan duruma bağlı olmaması demektir. Bu önemlidir çünkü test runner'ları testleri istediği sırayla (ve genellikle paralel) çalıştırmakta serbesttir; testler mutable durumu sıfırlamadan paylaşıyorsa sonuçlar sıraya bağımlı ve kararsız (flaky) hâle gelir. Mock kullanılıp kullanılmamasıyla ilgisizdir ve unit testler için de integration testler kadar geçerlidir.
Csharp Testing ToolingZorluk 2
public class CounterTests
{
    private int _count;

    public CounterTests()
    {
        _count = 10;
    }

    [Fact]
    public void FirstIncrements()
    {
        _count++;
        Assert.Equal(11, _count);
    }

    [Fact]
    public void SecondStartsFresh()
    {
        Assert.Equal(10, _count);
    }
}

İki test birlikte çalıştırıldığında ikisi de geçiyor. FirstIncrements'in _count = 11 bırakması neden SecondStartsFresh'i etkilemiyor?
  • aBu çalıştırma sırasının bir tesadüfüdür — SecondStartsFresh, herhangi bir yeniden başlatma olmadan aynı test sürecinde FirstIncrements'in hemen ardından çalışsaydı 11'i görürdü
  • bxUnit her [Fact] metodu için CounterTests'in yepyeni bir instance'ını oluşturur, bu yüzden constructor tekrar çalışır ve _count, SecondStartsFresh için yeniden 10'dan başlar✓
  • cTest runner, aynı nesnede bile her [Fact]'ten önce her instance alanını deklare edilmiş varsayılanına sıfırlar, constructor'ın ayarladığını geçersiz kılar
  • dSecondStartsFresh sadece geçer çünkü Assert.Equal(10, _count), canlı alan değerini değil FirstIncrements çalışmadan önce alınmış önbelleklenmiş bir anlık görüntüyü okur
Açıklama:xUnit her [Fact]/[Theory] metodu için test sınıfının yeni bir instance'ını oluşturur — constructor, diğer framework'lerdeki [SetUp]/[BeforeEach]'in yerini alan test-başına setup görevi görür. FirstIncrements ve SecondStartsFresh bu yüzden iki ayrı CounterTests nesnesi üzerinde çalışır, her biri kendi taze constructor çağrısını alır (_count = 10). Bir instance'daki _count'u mutasyona uğratmak diğer instance'ın alanını etkilemez.

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