Flutter Test Rehberi: Widget Test, Integration Test ve Golden Test ile 2026 Mulakatlarina Hazirlik

Flutter ile uygulama gelistirebilmek artik tek basina yeterli bir yetkinlik olarak kabul edilmiyor. 2026 yilinda teknik mulakatlarda adaylardan beklenen, yazdiklari kodun calistigini kanitlayabilmeleri, regresyonlara karsi dayanikliligini gosterebilmeleri ve mevcut kod tabanini bozmadan yeni ozellikler ekleyebildiklerini ortaya koymaktir. Test yazma becerisi, arayuz olusturma becerisinden bagimsiz bir degerlendirme kriteri haline gelmistir. Flutter'i uretim ortaminda kullanan ekipler, ise alim sureclerinde test kapsamini ve test kalitesini kod kalitesiyle esit duzeyde degerlendirmektedir.

Bu makale, Flutter test ekosistemini mulakat odakli ve uygulamali bir perspektifle ele almaktadir. Her bolum, teknik mulakatlarda dogrudan degerlendirilen bir yetkinlige karsilik gelmekte ve hemen uygulanabilir kod ornekleriyle desteklenmektedir. Amac, ansiklopedik bir katalog sunmak degil; temel mekanizmalari ve bunlarin birbirleriyle iliskilerini saglam bir sekilde kavratmaktir.

Widget Testing: Kullanicinin Gordugunu Dogrulamak

Widget testi, Flutter test ekosisteminin en ayirt edici unsurudur. Skaler degerler uzerinde calisilan klasik birim testlerinden farkli olarak, widget testi gorsel bilesen agaci uzerinde islem yapmaktadir. Framework, tam render dongusunu herhangi bir cihaz veya emulator gerektirmeksizin simule ederek testlerin hizli ve belirlenimci sekilde calismasini saglamaktadir.

WidgetTester, gercek bir kullanicinin hareketlerini yeniden ureten bir API sunmaktadir: bir butona dokunmak, metin girmek, bir listeyi kaydirmak. Finder siniflari, bilesen agacindaki elemanlari metin, tip, ikon veya anahtar (key) ile bulmaktadir. Matcher'lar ise bu elemanlarin varligini, yoklugunu veya sayisini dogrulamaktadir.

Asagidaki test, bir sayac bileseninin artirma butonuna basildigindaki davranisini dogrulamaktadir.

import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:my_app/counter_widget.dart';

void main() {
  testWidgets('Counter increments on tap', (WidgetTester tester) async {
    await tester.pumpWidget(
      const MaterialApp(home: CounterWidget()),
    );

    expect(find.text('0'), findsOneWidget);
    expect(find.text('1'), findsNothing);

    await tester.tap(find.byIcon(Icons.add));
    await tester.pump();

    expect(find.text('0'), findsNothing);
    expect(find.text('1'), findsOneWidget);
  });
}

Bu testte dikkat edilmesi gereken birkac kritik karar bulunmaktadir. Widget, bir MaterialApp icerisine sarilmistir; cunku Flutter bilesenlerinin buyuk cogunlugu bu kok bilesen tarafindan saglanan InheritedWidget'lara (tema, metin yonlendirmeleri, navigasyon) bagimlidir. Bu sarginin olmamasi, test ortaminda anlasilmasi guc hatalara yol acmaktadir.

tap() isleminden sonra cagirilan pump(), tam olarak bir yeniden olusturma karesi tetiklemektedir. Bu mekanizma, test edilen bilesenin durumu uzerinde cerrahi bir kontrol saglar: gelistirici, dogrulama anini kesin olarak belirlemektedir. Dogrulamalar (assertions), ekranda gorunen metin uzerinden yapilmakta, asla bilesenin ic durumuna erisilerek gerceklestirilmemektedir. Bu "disaridan iceriye" yaklasimi, uygulama detaylari degisse bile gozlemlenebilir davranis ayni kaldigi surece testlerin gecerliligini korumasini saglamaktadir.

Bu yaklasim, Arrange-Act-Assert (Hazirlama-Eyleme Gecme-Dogrulama) kalibina tam olarak uymaktadir: widget olusturulur (Arrange), kullanici etkilesimi simule edilir (Act) ve beklenen sonuc dogrulanir (Assert). Mulakatlarda bu kalibin bilinmesi ve uygulanmasi, adayin test yazma konusundaki sistematik yaklasimini ortaya koymaktadir.

Asenkron Islemler ve Stream Tabanli Widget'larin Test Edilmesi

Uretim Flutter uygulamalari, basit senkron sayaclarin cok otesindedir. Gercek dunyada widget'lar sunucudan veri yuklemekte, bekleme sirasinda yukleniyor gostergesi sunmakta ve ardindan sonucu goruntulmektedir. Bu tam donguyu test etmek, pumping mekanizmasinin hakimiyetini ve dis bagimliliklari simule etmek icin mock kullanmini gerektirmektedir.

Asagidaki test, asenkron bir repository'yi sorgulayan bir kullanici profili bilesenini dogrulamaktadir.

import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:my_app/user_profile_widget.dart';
import 'package:my_app/user_repository.dart';

class MockUserRepository extends Mock implements UserRepository {}

void main() {
  late MockUserRepository mockRepo;

  setUp(() {
    mockRepo = MockUserRepository();
  });

  testWidgets('displays user name after loading', (tester) async {
    when(() => mockRepo.fetchUser(1)).thenAnswer(
      (_) async => User(id: 1, name: 'Alice'),
    );

    await tester.pumpWidget(
      MaterialApp(
        home: UserProfileWidget(repository: mockRepo),
      ),
    );

    expect(find.byType(CircularProgressIndicator), findsOneWidget);

    await tester.pumpAndSettle();

    expect(find.text('Alice'), findsOneWidget);
    expect(find.byType(CircularProgressIndicator), findsNothing);

    verify(() => mockRepo.fetchUser(1)).called(1);
  });
}

Bir onceki testle arasindaki belirleyici fark, pump() yerine pumpAndSettle() kullanimindir. Bu metot, bilesen agaci tamamen dengelenene kadar -- bekleyen kare kalmayincaya, devam eden animasyon bitinceye ve askida microtask kalmayincaya kadar -- pump() islemini dongude cagirmaktadir. Future cozumlenme suresinin belirsiz oldugu senaryolar icin idealdir.

Ancak pumpAndSettle() onemli bir tuzak icermektedir ve teknik mulakatlarda bu konu siklilkla sorulmaktadir: sonsuz bir animasyon aktifse bu metot zaman asimina ugrar. Surekli donen bir CircularProgressIndicator (ornegin yukleme mantidindaki bir hata nedeniyle), testin assertion'dan degil zaman asimi nedeniyle basarisiz olmasina neden olur. Bu durumda pump(const Duration(seconds: 2)) daha kontrolllu bir alternatif sunmaktadir.

verify(() => mockRepo.fetchUser(1)).called(1) dogrulamasi, basit testlerde nadiren bulunan bir boyut eklemektedir: widget'in repository'yi birden fazla kez cagirmamis oldugunun garantisini saglamaktadir. Cift cagirim, widget yasam dongusunde bir sorunun -- ornegin her yeniden olusturmada yuklemeyi tetikleyen bir initState -- isareti olabilmektedir.

Mocktail ile Mocking Stratejileri

Dogrudan HTTP API cagiran, telefonun yerel servislerine erisen veya yerel veritabanina baglanan kod, izole olarak test edilememektedir. Temel teknik, widget ile dis bagimlilik arasina bir soyutlama katmani yerlestirmek ve somut uygulamayi constructor uzerinden enjekte etmektir. Bu yaklasim, SOLID ilkelerinin Dependency Inversion prensibinin dogrudan bir uygulamasidir.

Asagidaki hava durumu servisi bu mimariyi orneklemektedir.

abstract class WeatherService {
  Future<Weather> getWeather(String city);
}

class OpenMeteoWeatherService implements WeatherService {
  final http.Client _client;

  OpenMeteoWeatherService(this._client);

  @override
  Future<Weather> getWeather(String city) async {
    final response = await _client.get(
      Uri.parse('https://api.open-meteo.com/v1/forecast?city=$city'),
    );
    return Weather.fromJson(jsonDecode(response.body));
  }
}

Soyut WeatherService sinifi bir sozlesme tanimlamaktadir. OpenMeteoWeatherService uygulamasi, HTTP istemcisini bagimlilik enjeksiyonu yoluyla almaktadir. Uretim ortaminda constructor'a gercek bir http.Client() verilirken, test ortaminda bir mock verilmektedir. Servisin kendisi hangi istemciyi kullandigini bilmemektedir ve bilmemesi de gerekmektedir.

Mocktail kutuphanesi, Dart'ta mock olusturmayi kod uretimi gerektirmeyen sade bir sozdizimi ile saglamaktadir. Ilgili test yalnizca parsing mantgina odaklanmaktadir.

class MockHttpClient extends Mock implements http.Client {}

void main() {
  late MockHttpClient mockClient;
  late OpenMeteoWeatherService service;

  setUp(() {
    mockClient = MockHttpClient();
    service = OpenMeteoWeatherService(mockClient);
  });

  test('parses weather JSON correctly', () async {
    when(() => mockClient.get(any())).thenAnswer(
      (_) async => http.Response(
        '{"temperature": 22.5, "condition": "sunny"}',
        200,
      ),
    );

    final weather = await service.getWeather('Paris');

    expect(weather.temperature, 22.5);
    expect(weather.condition, 'sunny');
  });
}

Mock, onceden belirlenmis bir JSON yaniti dondurerek tum ag bagimliligini ortadan kaldirmaktadir. Test milisaniyeler icerisinde calisir, belirlenimci bir sonuc uretir ve tam olarak degerlendirilen mantigi -- bir JSON payload'inin Dart is nesnesine donusturulmesini -- hedef almaktadir.

any() matcher'i, get() metoduna gecirilen herhangi bir URI'yi kabul etmektedir. Bu tercih bilineli yapilmistir: testin amaci URL olusturmayui degil parsing'i dogrulamaktir. URL dogrulamasi gerekirse, bu davranis icin daha kisitlayici bir matcher kullanan ayri bir test yazilmalidir. Testlerde bu sorumluluk ayrimini uygulamak, uretim kodunda uygulanan ayni ilkeyi yansitmaktadir.

Entegrasyon Testleri: Uctan Uca Kullanici Akislarinin Dogrulanmasi

Entegrasyon testleri, test piramidinin en ust katmanini temsil etmektedir. Uygulamayi bir emulator veya fiziksel cihaz uzerinde tamamen baslatarak ekranlar arasinda gezinen, formlar dolduran ve sonuclari bekleyen gercek bir kullaniciyi simule etmektedir. Flutter SDK'sindaki integration_test paketi, yurutme cercevesini saglamaktadir.

Asagidaki ornek, eksiksiz bir kimlik dogrulama akisini dogrulamaktadir.

import 'package:flutter_test/flutter_test.dart';
import 'package:integration_test/integration_test.dart';
import 'package:my_app/main.dart' as app;

void main() {
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();

  testWidgets('complete login flow', (tester) async {
    app.main();
    await tester.pumpAndSettle();

    await tester.tap(find.text('Sign In'));
    await tester.pumpAndSettle();

    await tester.enterText(
      find.byKey(const Key('email_field')),
      'test@example.com',
    );
    await tester.enterText(
      find.byKey(const Key('password_field')),
      'securePassword123',
    );

    await tester.tap(find.byKey(const Key('login_button')));
    await tester.pumpAndSettle();

    expect(find.text('Dashboard'), findsOneWidget);
  });
}

IntegrationTestWidgetsFlutterBinding.ensureInitialized() cagrisi, standart binding'i platform ana bilgisayariyla iletisim kurabilen ozel bir binding ile degistirmektedir. Bu ozel binding, ekran goruntuleri yakalama, performans metriklerini toplama ve sistem yerel servisleriyle etkilesim kurma yetenegine sahiptir.

app.main() cagrisi, uygulamayi tumuyule baslatmaktadir: provider'lar, yonlendirici, servisler, bagimlilik enjeksiyonu. Hicbir sey simule edilmemektedir. Entegrasyon testlerine essiz degerini veren tam da bu kapsayyiciliktir: izole widget testlerinin tespit edemeyecegi bilesenler arasi baglanti sorunlarini ortaya cikarmaktadir.

Form alanlarini bulmak icin find.byKey(const Key(...)) kullanimi, cokllu dil destekli projelerde vazgecilmez bir pratiktir. find.text() kullanimindan farkli olarak, key'ler aktif dile gore degismemektedir. Bu kararlilik, ayni test paketinin tum dil yapilandirmalarinda calismasini garantilemektedir.

Mulakat icin onemli bir nokta: entegrasyon testleri yavas, kaynak yoğun ve flakiness'e (rastgele kararsizlik) egilimlidir. Deneyimli bir aday, bu testlerin yalnizca kritik yollari -- giris, odeme, kayit -- kapsamasi gerektigini ve saglam bir widget test temeli olusturmanin kapsam/yurutme suresi orani acisindan en iyi yatirim oldugunu bilmektedir. Daha gelismis entegrasyon test ihtiyaclari icin Patrol gibi araclar, yerel isletim sistemi ozellikleriyle etkilesimi kolaylastirmaktadir.

Golden Test: Otomatik Gorsel Regresyon Tespiti

Golden testler, ne birim testlerinin ne de klasik widget testlerinin kapsadigi bir boyutu sunmaktadir: bir bilesenin tam gorunumunun dogrulanmasi. Ilke, bir widget'in mevcut render'ini ekip tarafindan onaylanan bir referans goruntuyle karsilastirmaktir. Tek bir piksel farki bile testin basarisiz olmasina neden olmaktadir.

import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:my_app/primary_button.dart';

void main() {
  testWidgets('PrimaryButton matches golden file', (tester) async {
    await tester.pumpWidget(
      MaterialApp(
        home: Scaffold(
          body: Center(
            child: PrimaryButton(
              label: 'Submit',
              onPressed: () {},
            ),
          ),
        ),
      ),
    );

    await expectLater(
      find.byType(PrimaryButton),
      matchesGoldenFile('goldens/primary_button.png'),
    );
  });
}

Referans goruntulerin ilk olusturulma islemi flutter test --update-goldens komutuyla gerceklestirilmektedir. Bu komut, sonraki tum yurutmelerde temel olarak kullanilacak PNG dosyalarini olusturmaktadir. Bir test basarisiz oldugunda Flutter, beklenen render ile elde edilen render'i yan yana gosteren bir karsilastirma goruntusu uretir ve regresyonun gorsel analizini kolaylastirmaktadir.

Golden testler, ozellikle tasarim sistemi (design system) idame ettiren ekipler icin degerlidir. Paylesilan bir bilesendeki yanlislikla yapilmis bir renk, bosluk veya tipografi degisikligi, kod incelemesinden once otomatik olarak tespit edilmektedir. Ancak bu teknik bilinen bir tuzak icermektedir: isletim sistemleri arasindaki render farkliliklari. Ayni widget, yazi tipi render'lama ve kenar yumusatma (anti-aliasing) farkliliklari nedeniyle macOS, Linux ve Windows'ta farkli goruntuler uretebilmektedir.

Onerilen uygulama, golden dosyalarinin yalnizca standart bir ortamda -- tipik olarak CI/CD pipeline'indaki bir Docker konteynerinde -- olusturulup dogrulanmasidir. Alchemist gibi araclar, golden testlerinin coklu tema ve boyut varyasyonlarinda sistematik olarak calistirilmasini saglamaktadir.

Test Yapisi ve Organizasyonu

Acik bir organizasyona sahip olmayan bir test paketi hizla degerini yitirmektedir. Test dosyalari, projenin yapisini yansitmali ve kategoriye, ekrana veya ozellge gore secimli yurutmeye olanak tanimalidir. Flutter resmi test dokumantasyonu da bu yapiyi onermektedir.

test/
  unit/
    services/
      weather_service_test.dart
    models/
      user_test.dart
  widget/
    screens/
      login_screen_test.dart
      dashboard_test.dart
    components/
      primary_button_test.dart
  goldens/
    primary_button.png
integration_test/
  login_flow_test.dart
  checkout_flow_test.dart

Bu agac yapisi sorumlulklari net olarak ayirmaktadir. test/unit/ dizini, saf is mantigi dogrulamasini icermektedir: servisler, modeller, yardimci fonksiyonlar. test/widget/ dizini, gorsel bilesen testlerini ekranlar ve yeniden kullanilabilir bilesenler olarak organize etmektedir. test/goldens/ dizini referans goruntuleri barindirmaktadir. SDK'nin resmi kurali geregi proje kokune yerlestirilen integration_test/ dizini, uctan uca senaryolari icermektedir.

Bu organizasyon dogrudan operasyonel bir avantaj sunmaktadir: hedefli alt kumelerin calistirilabilmesi. Bir giris ekrani gelistirilirken flutter test test/widget/screens/login_screen_test.dart komutu, tum paketin calistirilmasina gerek kalmaksizin aninda geri bildirim saglamaktadir. Daha yavas olan entegrasyon testleri CI pipeline'ina ayrilmaktadir.

Kod kapsami flutter test --coverage komutuyla olculur ve bir lcov.info dosyasi olusturulur. Profesyonel ortamlarda genellikle beklenen esikler, servisler ve is mantigi icin %80 ve ana ekranlarla kritik yollar icin hedefli kapsamdir. Ancak nicel kapsam, dogrulama kalitesini golgelememelidir: trivial assertion'larla %100 test edilen bir dosya, guvenirlilk acisindan hicbir garanti sunmamaktadir.

Mulakatlarda Sik Sorulan Sorular ve Cevap Stratejileri

Flutter mulakatlarinda test ile ilgili sorular, sozdizimi ezberlenmesini olcmeyi hedeflememektedir. Degerlendirilen, altta yatan ilkelerin kavranmasi, belirsiz senaryolar karsisinda muhakeme yetenegei ve adayin uretim ortamindaki test paketleriyle gercek deneyimidir.

pump() ile pumpAndSettle() arasindaki fark nedir?

pump() tam olarak bir yeniden olusturma karesi tetikler ve gelistiriciye dogrulama zamanlmasi uzerinde kesin kontrol saglar. pumpAndSettle() ise bilesen agaci tamamen dengelenene kadar -- animasyonlar bitinceye, microtask'lar tamamlanincaya kadar -- pump() islemini tekrarlar. Sonsuz bir animasyon durumunda pumpAndSettle() zaman asimina ugrar; bu nedenle pump(Duration(...)) ile belirli bir sure ilerleterek bu durumun asilmasi gerekmektedir.

Riverpod kullanan bir widget nasil test edilir?

Riverpod'un ProviderScope bileseni, overrides parametresi araciliyla herhangi bir provider'in test uygulamasiyla degistirilmesine olanak tanmaktadir. Her test kendi ProviderScope'unda calistigi icin testler arasi durum kirlenmesi onlenmektedir.

import 'package:flutter_riverpod/flutter_riverpod.dart';

testWidgets('CartWidget shows item count', (tester) async {
  await tester.pumpWidget(
    ProviderScope(
      overrides: [
        cartProvider.overrideWith(
          (ref) => CartNotifier(initialItems: [
            CartItem(name: 'Widget Book', price: 29.99),
          ]),
        ),
      ],
      child: const MaterialApp(home: CartWidget()),
    ),
  );

  expect(find.text('1 item'), findsOneWidget);
  expect(find.text('\$29.99'), findsOneWidget);
});

overrideWith metodu, notifier'in mantgini koruyarak baslangic verilerini kontrol altina almaktadir. Bu teknik, provider'i statik bir degerle degistirip notifier mantginii devre disi birakan overrideWithValue'dan farklilasir. Ikisi arasindaki tercih, istenen sadakat duzeyine baglidir.

Golden test ne zaman klasik widget testi yerine tercih edilmelidir?

Klasik widget testi, elemanlarin varligini ve davranisini dogrular. Golden test ise tam gorunumlerini dogrular. Ikisi birbirini tamamlamaktadir. Golden test, gorunumu kritik olan tasarim sistemi bilesenleri (butonlar, kartlar, form alanlari) icin uygundur. Yerlesimi sik degisen bir ekran icin ise gereksiz bir maliyet olusturur.

Test edilebilir kod nasil yazilir?

Test edilebilirligin temeli, bagimliliklarin soyutlanmasi ve constructor uzerinden enjekte edilmesidir. Dogrudan bir HTTP istemcisi, veritabani baglantisi veya platform servisi cagiran kod izole olarak test edilememektedir. Soyut sinif veya arayuz tanimlanir, somut uygulama bu sozlesmeyi gerceklestirir ve test sirasinda mock ile degistirilir. Bu yaklasim SOLID ilkelerinin dogrudan uygulamasidir.

Entegrasyon testlerinde flakiness (rastgele kararsizlik) nasil yonetilir?

Flakiness genellikle kontrol edilemeyen ag gecikmeleri, suresi degisen animasyonlar veya thread'ler arasi yaris kosullarindan kaynaklanmaktadir. Cozumler arasinda entegrasyon testlerinde ag cagrilari icin mock kullanimi, kritik diziler icin pumpAndSettle() yerine pump(Duration(...)) ile acik gecikme eklenmesi ve Docker uzerinden yurutme ortaminin standartlastirilmasi yer almaktadir.

Sonuc

2026 yilinda Flutter test yetkinligi, flutter_test paketinin API'sini bilmenin cok otesinde bir anlam tasimaktadir. Mimari bir bakis acisi gerektirmektedir: widget testi ile entegrasyon testi arasindaki sinirin nereye konulmasi gerektigini bilmek, bagimlilik enjeksiyonunun test edilebilirligi nasil belirledigini kavramak ve guvenilir bir testi kirilgan bir testten ayiran pumping dongusu inceliklerine hakim olmak.

Teknik mulakatlar icin akilda tutulmasi gereken temel yetkinlikler:

• Widget testi, emulator veya fiziksel cihaz gerektirmeksizin render ve etkilesimleri dogruulayarak Flutter test piramidinde en iyi maliyet-fayda oranini sunmaktadir
• pump() ile pumpAndSettle() arasindaki fark, render dongusunun kavranmasini ortaya koyar ve mulakatlarda tekrarlayan bir soru konusudur
• Mocktail ile mocking ve constructor tabanli bagimlilik enjeksiyonu, test edilmesi dogasi geregi zor olan kodu moduler ve dogrulanabilir hale getirmektedir
• Entegrasyon testleri, uctan uca kritik akislari dogrulamaktadir; ancak yurutme maliyetleri ve kirilganliklari nedeniyle yuksek is degeri tasiyan akislara ayrilmalari gerekmektedir
• Golden testler, fonksiyonel testlerin goremeyecegi gorsel regresyonlari tespit etmektedir; ancak referans goruntulerin standart bir ortamda olusturulmasi kosulu bulunmaktadir
• Test paketinin ayri dizinlerde (birim, widget, golden, entegrasyon) organize edilmesi, secimli yurutmeyi mumkun kilmakta ve projenin teknik olgunlugunu yansitmaktadir
• Riverpod provider surcharging mekanizmasi ProviderScope uzerinden uretim kodunda degisiklik yapmaksizin testler arasi tam izolasyon saglamaktadir

Flutter ise alim sureclerinde test yazma, yapilandirma ve gerekcelendirme becerisi, guvenilir yazilim teslim edebilen adaylari yalnizca arayuz olusturabilen adaylardan ayirmaktadir. Bu yetkinlik, gercek projeler uzerinde duzenmli pratikle insa edilir ve yazilan her test, mulakatlarin en zorlu sorularini guvenlke karsilmak icin gerekli teknik ozguveni pekistirmektedir.

SharpSkill uzerinde Flutter test becerilerinizi pratik sorularla gelistirmek icin Widget Testing Modulu ve Unit Testing Modulu sayfalarini inceleyebilirsiniz.