• Birim Testleri (Unit Tests): Uygulamanızın en küçük, izole edilmiş bileşenlerini (metotlar, sınıflar) test eder. Amaç, her bir parçanın tek başına doğru çalıştığından emin olmaktır.
• Entegrasyon Testleri (Integration Tests): Farklı birimlerin bir araya geldiğinde doğru çalışıp çalışmadığını kontrol eder. Örneğin, bir kullanıcının kaydolma akışı, veritabanı etkileşimleri veya harici API çağrıları gibi senaryoları kapsar.
• Sistem/Özellik Testleri (System/Feature Tests): Uygulamanın uçtan uca, gerçek bir kullanıcı gibi test edilmesini sağlar. Genellikle tarayıcı otomasyon araçları (örneğin Capybara) kullanılarak web arayüzü üzerinden kullanıcı etkileşimleri simüle edilir. Bu testler, uygulamanın genel işlevselliğini ve kullanıcı deneyimini doğrulamak için kritik öneme sahiptir.

group :development, :test do
  gem 'rspec-rails' # Rails uygulamaları için
  # gem 'rspec' # Saf Ruby projeleri için
end

# spec/models/kullanici_spec.rb
require 'rails_helper'

RSpec.describe Kullanici, type: :model do
  it 'geçerli niteliklerle kaydedilmeli' do
    kullanici = Kullanici.new(isim: 'Ali', email: 'ali@example.com')
    expect(kullanici).to be_valid
  end

  it 'geçerli olmayan bir e-posta ile kaydedilemez' do
    kullanici = Kullanici.new(isim: 'Ayşe', email: 'ayse@gecersiz')
    expect(kullanici).to_not be_valid
    expect(kullanici.errors[:email]).to include('geçersiz formatta')
  end

  context 'isim alanı boş olduğunda' do
    it 'geçersiz olmalı' do
      kullanici = Kullanici.new(isim: '', email: 'deneme@example.com')
      expect(kullanici).to_not be_valid
      expect(kullanici.errors[:isim]).to include('boş bırakılamaz')
    end
  end
end

• `expect(value).to eq(expected)`: Eşitlik kontrolü.
• `expect(value).to be_nil`: Boş olup olmadığını kontrol eder.
• `expect(array).to include(item)`: Dizide bir öğenin olup olmadığını kontrol eder.
• `expect { code }.to raise_error(ErrorClass)`: Belirli bir hatanın fırlatılıp fırlatılmadığını kontrol eder.
• `expect(object).to be_valid`: ActiveRecord nesnelerinin geçerliliğini kontrol eder.

• Stubbing: Bir nesnenin belirli bir metodu çağrıldığında sabit bir değer döndürmesini sağlamak.
  
  Kod:

  allow(API_Client).to receive(:get_data).and_return({ status: 'ok' })

• Mocking: Bir nesnenin belirli bir metotla belirli bir sayıda veya belirli argümanlarla çağrıldığını doğrulamak.
  
  Kod:

  expect(UserMailer).to receive(:welcome_email).with(user).and_return(double.as_null_object)

"İyi yazılmış bir test, neden başarısız olduğunu açıkça göstermelidir." - Gojko Adzic

Genişletmek için tıkla ...

group :development, :test do
  gem 'minitest'
  gem 'minitest-reporters' # Çıktıyı güzelleştirmek için
end

# test/models/urun_test.rb
require 'test_helper'

class UrunTest < ActiveSupport::TestCase
  test 'ürün adı boş olamaz' do
    urun = Urun.new(fiyat: 100)
    assert_not urun.valid?
    assert_includes urun.errors[:ad], 'boş bırakılamaz'
  end

  test 'ürün fiyatı pozitif olmalı' do
    urun = Uun.new(ad: 'Kalem', fiyat: -5)
    assert_not urun.valid?
    assert_includes urun.errors[:fiyat], 'pozitif olmalı'
  end
end

• `assert_equal(expected, actual)`: Eşitlik kontrolü.
• `assert_nil(object)`: Boş olup olmadığını kontrol eder.
• `assert_includes(collection, object)`: Bir koleksiyonda öğe olup olmadığını kontrol eder.
• `assert_raises(ErrorClass) { code }`: Belirli bir hatanın fırlatılıp fırlatılmadığını kontrol eder.
• `assert(condition)`: Genel doğrulama.

• Red (Kırmızı): Öncelikle başarısız olacak bir test yazılır. Bu, geliştirmek istediğiniz yeni özelliği veya düzeltmeniz gereken hatayı açıkça belirtir.
• Green (Yeşil): Testi geçecek kadar minimum kodu yazılır. Bu aşamada kodun kalitesi veya refactoring düşünülmez, sadece testin geçmesi hedeflenir.
• Refactor (Yeniden Yapılandırma): Kod temizlenir, optimize edilir ve okunabilirliği artırılır. Bu sırada testlerin hala başarılı olduğundan emin olunur.

• Hızlı Testler: Testlerin hızlı çalışması, geliştirme sürecini hızlandırır ve düzenli test çalıştırmayı teşvik eder. Uzun süren testler genellikle bir yerlerde tıkanıklık olduğunu gösterir (örneğin, gerçek veritabanı veya harici API çağrıları). Bu tür durumlarda stubbing ve mocking kullanın.
• İzole Testler: Her testin birbirinden bağımsız olması ve birbirini etkilememesi esastır. Bir testin başarısız olması, sadece o testin hedeflediği kod parçasında sorun olduğunu göstermelidir. Testler arasında ortak durum (state) paylaşımından kaçının.
• Okunabilir Testler: Test kodunuz, neyi test ettiğini ve neden test ettiğini açıkça belirtmelidir. `describe` ve `it` bloklarının anlamlı isimler taşıması, testin amacını kolayca anlamayı sağlar. DRY (Don't Repeat Yourself) prensibini testlerde de uygulayın ancak okunabilirlik pahasına değil.
• Tek Bir Sorumluluk Prensibi (SRP): Her testin tek bir şeyi test etmeye odaklanması önerilir. Bu, bir testin başarısız olduğunda hatanın kaynağını bulmayı kolaylaştırır.
• Uç Durumları Test Etmek: Pozitif senaryoların yanı sıra, geçersiz girdiler, boş değerler, sınır koşulları ve hata durumları gibi uç durumları da test ettiğinizden emin olun.
• Bağımlılıkları Yönetmek: Harici servisler, veritabanları veya dosya sistemleri gibi bağımlılıkları testlerinizden izole etmek için mocking ve stubbing tekniklerini kullanın. Bu, testlerin daha hızlı ve güvenilir olmasını sağlar.
• Sürekli Entegrasyon (CI) ile Testleri Otomatize Etmek: Testlerinizi her kod değişikliğinde otomatik olarak çalıştıracak bir CI sistemi (örneğin GitHub Actions, GitLab CI, Jenkins) kurmak, hataların erken tespit edilmesini sağlar ve üretim ortamına ulaşan hatalı kod miktarını önemli ölçüde azaltır.

"Kodu test etmemek, el freni çekili araba kullanmaya benzer. Belki gidersiniz ama çok daha yavaş ve hasar riskiniz yüksek olur." - Anonim

Genişletmek için tıkla ...