Test nedir?

Yazılım yazarken test yaparak yazılımın düzgün çalıştığını doğrulayabilirsiniz. Test geniş kapsamlı bir yazılımı, yazılımın amaçlandığı gibi işlediğinden emin olmak için belirli şekillerde çalıştırma süreci olarak tanımlanabilir.

Başarılı testler, yeni kod, özellikler ekledikçe veya bağımlılıklarınızı yükselttikçe, önceden yazdığınız yazılımın beklediğiniz gibi çalışmaya devam edeceğinden emin olmanızı sağlar. Testler, yazılımınızı beklenmedik senaryolara veya beklenmedik girişlere karşı korumaya da yardımcı olabilir.

Web'de test etmek isteyebileceğiniz bazı davranış örnekleri aşağıda verilmiştir:

• Bir web sitesi özelliğinin bir düğme tıklandığında doğru şekilde çalışmasını sağlamak.
• Karmaşık bir fonksiyonun doğru sonuçları ürettiğini onaylama.
• Kullanıcı girişi gerektiren bir işlemi tamamlama.
• Bozuk veri girildiğinde formun hatayı doğru şekilde bildirip bildirmediğini kontrol etme.
• Kullanıcı çok düşük bant genişliğine sahip olduğunda veya çevrimdışı olduğunda karmaşık web uygulamasının çalışmaya devam etmesini sağlama.

Otomatik ve manuel test karşılaştırması

Yazılımınızı iki genel şekilde test edebilirsiniz: otomatik test ve manuel test.

Manuel test, gerçek kişilerin yazılımları doğrudan çalıştırmasını (örneğin, bir web sitesini tarayıcılarına yükleyip) beklendiği gibi davrandığını onaylamalarını içerir. Manuel testlerin oluşturulması veya tanımlanması kolaydır. Örneğin, siteniz yüklenebiliyor mu? Bu işlemleri yapabilir misiniz? Ancak her geçişin maliyeti çok fazladır. İnsanlar keşif testleri olarak bilinen bir tür test yapılmasını sağlayabilecek son derece yaratıcı insanlar olsa da, özellikle aynı görevi birçok kez yaparken hataları veya tutarsızlıkları fark etme konusunda başarılı olamayabiliriz.

Otomatik test, bir insanın kurulum veya sonuçları kontrol etme gibi tekrarlanan adımları gerçekleştirmesine gerek kalmadan, testlerin kodlanmasına ve bir bilgisayar tarafından tekrarlanan şekilde çalıştırılmasına olanak tanıyan bir süreçtir. Daha da önemlisi, otomatik test yapılandırıldıktan sonra sık sık çalıştırılabilir. Bu, hâlâ çok geniş bir tanımdır ve otomatik testlerin her türlü şekil ve biçimde olduğunu belirtmek önemlidir. Bu kursun büyük kısmı, uygulama olarak otomatik test yapmayla ilgilidir.

Manuel test ise genellikle otomatik test yazmanın öncüsü olarak, ancak aynı zamanda otomatik testler fazla güvenilmez, kapsamı geniş veya yazamayacak kadar elverişsiz hale geldiğinde de işe yarar.

Bir örnek üzerinden temel bilgiler

JavaScript veya ilgili diller yazan web geliştiricileri olarak bizim için kısa ve öz bir otomatik test, her gün (örneğin Düğüm üzerinden veya bir tarayıcıda yükleyerek) çalıştırdığınız aşağıdakine benzer bir komut dosyası olabilir:

import { fibonacci } from "../src/math.js";

if (fibonacci(0) !== 0) {
  throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
  throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}

Bu, aşağıdaki analizleri sağlayan basitleştirilmiş bir örnektir:

• Bu, bazı yazılımları (Fibonacci işlevi) çalıştırdığı ve sonuçların beklenen değerlere göre kontrol edilmesini sağlayarak davranışının amaçlandığı şekilde çalışmasını sağladığı için bir testtir. Davranış doğru değilse, JavaScript'in bir Error göndererek açıkladığı hataya neden olur.

• Bu komut dosyasını terminalinizde veya bir tarayıcıda manuel olarak çalıştırıyor olsanız bile, bu komut yine de otomatik bir testtir. Çünkü komut, tek tek adımlar yapmanıza gerek kalmadan tekrar tekrar çalıştırılabilir. Testlerin çalıştırıldığı bir sonraki sayfada daha ayrıntılı bilgi verilmektedir.

• Bu test herhangi bir kitaplık kullanmasa da (her yerde çalışabilen bir JavaScript'tir) yine de bir testtir. Bu kursun ilerleyen bölümlerinde ele alınacak olanlar da dahil olmak üzere test yazmanıza yardımcı olabilecek pek çok araç bulunur. Ancak hepsi, bir şeyler ters gittiğinde hataya neden olma temel ilkesi üzerinde çalışmaya devam eder.

Kitaplıkları uygulamalı olarak test etme

Çoğu kitaplık veya dahili test çerçevesi, testlerin daha kolay yazılmasını sağlayan iki temel temel öğe sağlar: onaylar ve bağımsız testleri tanımlamanın yolu. Bunlar, hak talepleri ve diğer temel öğeler adlı bir sonraki bölümde ayrıntılı olarak ele alınacaktır. Ancak, genel anlamda, gördüğünüz veya yazdığınız neredeyse tüm testlerin bu tür temel öğelerin kullanıldığından emin olmak önemlidir.

Onaylama, bir sonucun kontrol edilmesi ve bir şeyler ters gittiğinde hataya neden olma durumunu birleştirmenin bir yoludur. Örneğin, assert kullanarak önceki testi daha kısa ve öz hale getirebilirsiniz:

import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";

assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");

İsteğe bağlı olarak paketler halinde gruplanmış bağımsız testler tanımlayarak bu testi daha da iyileştirebilirsiniz. Aşağıdaki paket, Fibonacci işlevini ve Katalanca işlevini bağımsız olarak test eder:

import { fibonacci, catalan } from "../src/math.js";
import { assert, test, suite } from "a-made-up-testing-library";

suite("math tests", () => {
  test("fibonacci function", () => {
    assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
    assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
  });
  test("relationship between sequences", () => {
    const numberToCheck = 4;
    const fib = fibonacci(numberToCheck);
    const cat = catalan(numberToCheck);
    assert.isAbove(fib, cat);
  });
});

Bu yazılım testi bağlamında test isim olarak bir test senaryosunu belirtir: önceki örnekte verilen "diziler arasındaki ilişki" test durumu gibi tek, bağımsız, ele alınabilir bir senaryo.

Ayrı ayrı adlandırılmış testler, diğer görevlerin yanı sıra aşağıdaki görevler için yararlıdır:

• Bir testin zaman içinde nasıl başarılı veya başarısız olduğunu belirleme.
• Senaryonun çözülüp çözülmediğini daha kolay test edebilmeniz için bir hatayı veya senaryoyu ada göre vurgulama.
• Bazı testleri diğerlerinden bağımsız olarak (ör. glob filtresi aracılığıyla) çalıştırma.

Test durumlarını düşünmenin yollarından biri, birim testinin "üç A"sını kullanmaktır: Düzenle, harekete geç ve doğrula. Her test senaryosu özünde:

• Bazı değerleri veya durumu düzenleyin (bu sadece sabit kodlanmış giriş verileri olabilir).
• Yöntem çağırma gibi bir işlem gerçekleştirin.
• Çıkış değerlerini veya güncellenmiş durumu bildirin (assert kullanarak).

Testlerin ölçeği

Önceki bölümde yer alan kod örneklerinde, yazılımınızın küçük bölümlerini test edip genellikle tek bir dosyaya odaklanan ve bu örnekte yalnızca tek bir işlevin çıkışını test ettikleri birim testi açıklanmaktadır. Birden çok dosya, bileşen veya hatta farklı birbirine bağlı sistemlerden (ağ hizmeti veya harici bir bağımlılığın davranışı gibi kontrolünüzün dışında) kod yazmayı düşündüğünüzde testin karmaşıklığı artar. Bu nedenle, test türleri genellikle kapsamlarına veya ölçeklerine göre adlandırılır.

Birim testleri ile birlikte bileşen testi, görsel testler ve entegrasyon testi, diğer test türlerine örnek olarak verilebilir. Bu adların hiçbirinin kesin tanımları yoktur ve kod tabanınıza bağlı olarak farklı anlamları olabilir. Bu nedenle, bunları rehber olarak kullanmayı ve size uygun tanımlar bulmayı unutmayın. Örneğin, sisteminizde test edilen bileşen nedir? React geliştiricileri için bu işlem tam anlamıyla bir "React bileşeni" ile eşlenebilir, ancak başka bağlamlarda geliştiriciler için farklı bir anlama gelebilir.

Bireysel bir testin ölçeği, testi genellikle "test piramidi" olarak adlandırılan bir kavramın içine yerleştirebilir. Bu, testin neyi kontrol ettiği ve nasıl çalıştığı konusunda genel bir kural olabilir.

Bu fikir yinelendi ve şimdilerde test eması veya test buz konisi gibi çeşitli şekiller popüler hale geldi. Test yazma öncelikleriniz muhtemelen kod tabanınıza özgü olacaktır. Ancak yaygın bir özellik, birim testleri gibi daha basit testlerin daha hızlı çalıştırılması, yazılması daha kolay (böylece daha fazla sayıda testin olması) ve sınırlı bir kapsamın test edilmesidir. Uçtan uca testler gibi karmaşık testlerin ise yazılmasının zor olması ancak daha geniş bir kapsamı test edebilmesidir. Aslında, bazı kullanıcı etkileşimleri otomatik bir teste kodlanamayacak kadar karmaşık olduğundan, birçok test "şeklinin" en üst katmanı manuel test yapma eğilimindedir.

Bu türler, otomatik test türlerinde genişletilecektir.

Öğrendiklerinizi sınayın