DEV Community: Emin Şahin

Türkiye'de Sentry Logları Neden Dashboardda Görünmüyor?

Emin Şahin — Mon, 13 Apr 2026 17:35:37 +0000

Geliştirdiğim yeni uygulamada hata takibi için kullandığım Firebase Crashlytics'i bırakıp Sentry'e geçmeye karar verdim. Her şey çok standart ve kolay görünüyordu ancak Türkiye'deki internet servis sağlayıcılarının az bilinen bir engeline takılacağımı hiç tahmin etmemiştim. Saatlerimi çalan bu DNS yönlendirme (hijack) sorunu ve Sentry destek ekibinden gelen o tek kelimelik çözümü, benzer bir durum yaşayanlar için paylaşmak istedim.

Neden Sentry'ye Geçmek İstedim?

Uygulamada zaten Firebase ekosistemini (Auth, Firestore, Remote Config vs.) kullanıyorum. Hata takibi için de başlangıçta Crashlytics kullanıyordum. Ama proje büyüdükçe Crashlytics'in sunduğu hata gruplandırmaları bana yetersiz gelmeye başladı. Hem daha detaylı stack trace görebilmek hem de projeyi tamamen Firebase'e bağımlı yapmamak (vendor lock-in) için Sentry daha mantıklı geldi.

Kod tarafında Clean Architecture kullandığım için geçiş çok rahattı. Loglama işlerini soyutladığım için sadece arka plandaki entegrasyonu Sentry ile değiştirmem yetti.

Ortada Hata Var, Log Yok

Entegrasyonu bitirdim ve test etmek için bilerek bir hata fırlattım.

final sentryId = await Sentry.captureException(exception, stackTrace: stack);
print('Sentry Event ID: $sentryId');

Konsolda Sentry'nin bana verdiği Event ID sorunsuz yazdırıldı. SDK hatayı yakalamış ve sunucuya iletmiş gibi görünüyordu. Ancak Sentry paneline girdiğimde hiçbir issue göremiyordum. Ekranda hâla "Kuruluma Başla" adımları duruyordu.

Filtreler mi yanlış, DSN(Data Source Name) adresini mi eksik kopyaladım derken panelde hiçbir sorun bulamadım.

Debug Modunu Açınca Gelen Gerçek

SDK'nın arka planda ne yaptığını anlamak için Sentry'nin debug modunu aktif ettim. Önce Flutter konsolunda ağ isteklerini görmeyi bekledim ama hiçbir şey çıkmadı. Sentry, debug loglarını Flutter'a değil, doğrudan native platform konsollarına (iOS için Xcode) yazdırıyormuş.

Xcode konsolunu açtığımda asıl hatayı gördüm: İstekler zaman aşımına (timeout) uğruyordu.

NSURLErrorDomain Code=-1001 "The request timed out."
NSErrorFailingURLStringKey=[https://o4506359996481536.ingest.us.sentry.io/api/.../envelope/](https://o4506359996481536.ingest.us.sentry.io/api/.../envelope/)

İşin Aslı: DNS Engeli

Sorunun kodda değil ağda olduğunu anlayınca, Mac terminalinden Sentry adresine bir curl isteği attım; o da başarısız oldu. Sonra aklıma "Acaba DNS mi engelli?" sorusu geldi ve nslookup ile bir test yaptım.

Kendi internetimle sorguladığımda, İSS'lerin yasaklı siteleri yönlendirdiği Türkiye IP'si (195.175.254.2) döndü. Aynı sorguyu Google DNS (8.8.8.8) ile yapınca ise gerçek IP adresi (34.160.81.0) karşıma çıktı.

Durum netti: Türkiye'deki servis sağlayıcılar *.sentry.io domainini ulusal çapta, DNS seviyesinde engellemişti. Telefonun mobil verisinden denedim, orada da durum aynıydı.

Beni Oyalayan Yanlış İzler

Tabii sorunun kaynağını bulana kadar biraz zaman kaybettim:

Port Çakışması: Arka planda 443 portunda çalışan lokal bir SQL sunucusu vardı. İlk başta isteklerin bu yüzden kendi ağımda kaybolduğunu sandım.
VPN Yanılgısı: "VPN açarsam kesin düzelir" deyip denedim ama yine olmadı. Çünkü Mac'in DNS önbelleği eski IP'yi tutmaya devam ediyordu (dscacheutil -flushcache ile temizlemem gerekti).
Emülatör Sorunu: DNS'i temizlesem bile Android emülatörü ağı açılışta aldığı için eski ayarlarla kalmıştı. Emülatörü tamamen yeniden başlatmam gerektiğini geç fark ettim.

Destek Ekibinden Gelen Çözüm

Sorunu çözmek için Firebase Cloud Functions ile bir proxy yazmayı bile denedim. Yaklaşık 15 satırlık bir kodla istekleri *.cloudfunctions.net üzerinden geçirdim ve çalıştı. Ancak bu sefer de her log, Firebase faturama trafik maliyeti olarak yansıyacaktı. Son çare olarak Crashlytics'e geri dönmeyi düşünürken, Sentry destek ekibine bir e-posta attım.

Birkaç saat içinde döndüler ve çözüm son derece basitti: DSN adresindeki ingest.us.sentry.io kısmını ingest.tr.sentry.io yapmak.

Yeni DSN ile uygulamayı tekrar çalıştırdım ve her şey düzeldi. Bu subdomain, arka planda yine aynı IP adresine gidiyor ama İSS'lerin engelleme listesine takılmadığı için bağlantı sorunsuz kuruluyor.

Son Durum ve Tavsiye

Remote Config Kullanımı: Yeni .tr domaininin de bir gün engellenme ihtimaline karşı, DSN adresini artık Firebase Remote Config üzerinden uygulamaya veriyorum. Böylece yeni bir sorun çıkarsa mağazaya güncelleme göndermeden adresi değiştirebilirim.

Özetle, Türkiye'de Sentry kullanıyorsanız veya uygulamanızın Türkiye'den kullanıcıları varsa, varsayılan olarak gelen ABD sunucu adresi (US domain) çalışmıyor. Mutlaka .tr uzantılı ingest adresini kullanın. Ayrıca ağ isteklerinde anlam veremediğiniz timeout hataları alıyorsanız, nslookup domain.com 8.8.8.8 komutunu denemek sizi saatlerce debug yapmaktan kurtarabilir.

How I Achieved 100% Test Coverage in a Flutter Enterprise App

Emin Şahin — Mon, 09 Feb 2026 18:49:33 +0000

2,300+ tests. Zero excuses. Here's exactly how I did it.

The Challenge

When I started building an enterprise-grade Flutter starter app, I set myself an ambitious goal: 100% test coverage. Not 80%. Not 95%. Full coverage.

Why? Because I wanted to prove that Flutter apps can be tested thoroughly, and that good architecture makes comprehensive testing not just possible, but natural.

Two months later, I hit the target:

2,304+ tests
100% line coverage
Zero flaky tests

Here's the playbook.

1. Architecture That Enables Testing

The secret isn't writing more tests—it's writing testable code.

Clean Architecture + Hexagonal Pattern

┌─────────────────────────────────────────────────────────┐
│                    PRESENTATION                         │
│  Widgets, BLoCs, Cubits (UI logic)                     │
├─────────────────────────────────────────────────────────┤
│                    APPLICATION                          │
│  Use Cases, Services (orchestration)                   │
├─────────────────────────────────────────────────────────┤
│                      DOMAIN                             │
│  Entities, Ports (interfaces), Value Objects           │
├─────────────────────────────────────────────────────────┤
│                   INFRASTRUCTURE                        │
│  Repositories, Data Sources, APIs (implementations)    │
└─────────────────────────────────────────────────────────┘

Why this matters for testing:

Each layer can be tested in isolation
Dependencies always point inward
Ports (interfaces) make mocking trivial

CQRS Pattern

I separated queries (read operations) from commands (write operations):

// Query - simple data retrieval
final class GetUserProfile implements UseCase<UserProfile, NoParams> {
  GetUserProfile(this._repository);
  final IUserRepository _repository;

  @override
  Future<Either<Failure, UserProfile>> call(NoParams params) {
    return _repository.getUserProfile();
  }
}

// Command - state mutation
final class UpdateUserProfile implements UseCase<Unit, UpdateProfileParams> {
  UpdateUserProfile(this._repository);
  final IUserRepository _repository;

  @override
  Future<Either<Failure, Unit>> call(UpdateProfileParams params) {
    return _repository.updateProfile(params.name, params.email);
  }
}

Testing benefit: Each use case does ONE thing. One responsibility = one test focus.

2. The Test Pyramid

I followed a strict test pyramid:

         ╱╲
        ╱  ╲
       ╱ E2E╲        (~50 tests)
      ╱──────╲       Integration tests
     ╱ Widget ╲      (~400 tests)
    ╱──────────╲     UI component tests
   ╱    Unit    ╲    (~1,800 tests)
  ╱──────────────╲   Fast, isolated tests

Unit Tests (~80% of total)

The backbone. Fast, isolated, surgical.

group('GetUserProfile', () {
  late GetUserProfile useCase;
  late MockUserRepository mockRepository;

  setUp(() {
    mockRepository = MockUserRepository();
    useCase = GetUserProfile(mockRepository);
  });

  test('returns UserProfile when repository succeeds', () async {
    // Arrange
    final expectedProfile = UserProfile(id: '1', name: 'John');
    when(() => mockRepository.getUserProfile())
        .thenAnswer((_) async => Right(expectedProfile));

    // Act
    final result = await useCase(NoParams());

    // Assert
    expect(result, Right(expectedProfile));
    verify(() => mockRepository.getUserProfile()).called(1);
  });

  test('returns Failure when repository fails', () async {
    // Arrange
    when(() => mockRepository.getUserProfile())
        .thenAnswer((_) async => Left(ServerFailure()));

    // Act
    final result = await useCase(NoParams());

    // Assert
    expect(result, isA<Left<Failure, UserProfile>>());
  });
});

Widget Tests (~15% of total)

Test UI components in isolation:

testWidgets('LoginButton shows loading state', (tester) async {
  await tester.pumpApp(
    BlocProvider<AuthBloc>.value(
      value: mockAuthBloc,
      child: const LoginButton(),
    ),
  );

  // Simulate loading state
  whenListen(
    mockAuthBloc,
    Stream.fromIterable([const AuthState.loading()]),
  );
  await tester.pump();

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

Integration Tests (~5% of total)

End-to-end flows:

testWidgets('complete login flow', (tester) async {
  await tester.pumpWidget(const App());
  await tester.pumpAndSettle();

  // Enter credentials
  await tester.enterText(find.byKey(Key('email_field')), 'test@example.com');
  await tester.enterText(find.byKey(Key('password_field')), 'password123');

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

  // Verify navigation to dashboard
  expect(find.byType(DashboardPage), findsOneWidget);
});

3. Essential Tooling

`very_good_analysis`

VGV's strict lint rules catch issues before they become bugs:

# analysis_options.yaml
include: package:very_good_analysis/analysis_options.yaml

`mocktail` for Mocking

Much cleaner than mockito—no code generation needed:

class MockAuthRepository extends Mock implements IAuthRepository {}

// Usage
when(() => mockRepo.login(any(), any()))
    .thenAnswer((_) async => Right(user));

`bloc_test` for BLoC Testing

Makes testing state management dead simple:

blocTest<AuthBloc, AuthState>(
  'emits [loading, authenticated] when login succeeds',
  build: () {
    when(() => mockLoginUseCase(any()))
        .thenAnswer((_) async => Right(user));
    return AuthBloc(loginUseCase: mockLoginUseCase);
  },
  act: (bloc) => bloc.add(LoginRequested(email: 'test@test.com', password: '123')),
  expect: () => [
    const AuthState.loading(),
    AuthState.authenticated(user),
  ],
);

Coverage Commands

# Run tests with coverage
very_good test --coverage

# Generate HTML report
genhtml coverage/lcov.info -o coverage/html

# Open report
open coverage/html/index.html

4. Patterns That Make Testing Natural

Railway-Oriented Error Handling

Using fpdart's Either type eliminates try-catch chaos:

Future<Either<Failure, User>> login(String email, String password) async {
  return _authRepository
      .login(email, password)
      .flatMap((token) => _userRepository.getUser(token))
      .mapLeft((error) => AuthFailure.fromError(error));
}

Testing benefit: Every success AND failure path is explicit and testable.

Dependency Injection with `injectable`

@injectable
final class AuthBloc extends Bloc<AuthEvent, AuthState> {
  AuthBloc(this._loginUseCase, this._logoutUseCase) : super(AuthState.initial());

  final Login _loginUseCase;
  final Logout _logoutUseCase;
}

Testing benefit: Dependencies are injected, not created. Perfect for mocking.

Value Objects

Encapsulate validation in the type system:

final class Email {
  factory Email(String value) {
    if (!_emailRegex.hasMatch(value)) {
      throw InvalidEmailException(value);
    }
    return Email._(value);
  }

  const Email._(this.value);
  final String value;
}

Testing benefit: Invalid states are unrepresentable. Fewer edge cases to test.

5. Common Challenges & Solutions

Challenge: Testing Async Code

Solution: Use async/await and tester.pumpAndSettle():

testWidgets('shows data after loading', (tester) async {
  when(() => mockBloc.state).thenReturn(LoadingState());
  await tester.pumpApp(MyWidget());

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

  when(() => mockBloc.state).thenReturn(LoadedState(data));
  await tester.pumpAndSettle();

  expect(find.text('Data loaded'), findsOneWidget);
});

Challenge: Testing Navigation

Solution: Use GoRouter with navigatorKey:

testWidgets('navigates to profile on tap', (tester) async {
  final router = GoRouter(routes: [...], navigatorKey: navigatorKey);

  await tester.pumpWidget(
    MaterialApp.router(routerConfig: router),
  );

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

  expect(router.location, '/profile');
});

Challenge: Testing Time-Dependent Code

Solution: Inject a Clock dependency:

final class TokenValidator {
  TokenValidator(this._clock);
  final Clock _clock;

  bool isExpired(Token token) {
    return token.expiresAt.isBefore(_clock.now());
  }
}

// In tests
final mockClock = MockClock();
when(() => mockClock.now()).thenReturn(DateTime(2026, 2, 19));

6. The Results

After 2 months of disciplined testing:

Metric	Value
Total tests	2,304
Line coverage	100%
Branch coverage	98%+
Flaky tests	0
CI time	~4 minutes

What I Learned

100% coverage is achievable if you design for testability from day one
Architecture matters more than test quantity — good structure makes tests write themselves
The test pyramid is real — invest heavily in unit tests
Tools matter — bloc_test, mocktail, and very_good_analysis are game-changers

A Word of Caution

100% coverage isn't always the right goal. For this starter app, it made sense—it's a reference implementation meant to demonstrate best practices. But in production projects:

Refactoring becomes expensive — Every code change requires updating tests
Diminishing returns — Going from 80% to 100% often costs more than it's worth
False confidence — High coverage doesn't mean high-quality tests

Aim for meaningful coverage (70-90%) on critical paths rather than chasing a number. Test the logic that matters, not every getter and setter.

Try It Yourself

The entire codebase is open source:

🔗 GitHub: github.com/deveminsahin/starter_app

Every pattern I described is implemented and tested. Clone it, explore it, steal from it.

What's Next?

I'm writing follow-up articles on:

Railway-Oriented Error Handling in Flutter
Clean Architecture + DDD for Flutter
Mason Bricks for Feature Generation

Follow me for updates!

Found this helpful? Give the repo a ⭐ and share with a Flutter developer who might benefit.

flutter #testing #cleanarchitecture #dart #opensource #mobiledevelopment

CQRS Pattern in Flutter: Commands vs Queries

Emin Şahin — Sat, 24 Jan 2026 12:22:43 +0000

When building Flutter applications with Clean Architecture, one pattern that dramatically improves code clarity is Command Query Responsibility Segregation (CQRS).

In this article, I'll show you how I implement CQRS in a real Flutter project.

What is CQRS?

CQRS separates read operations (Queries) from write operations (Commands):

Type	Purpose	Side Effects
Command	Mutate state (create, update, delete)	Yes
Query	Read data	No

This separation makes your code:

✅ Easier to test (queries are always idempotent)
✅ Clearer intent (naming says what it does)
✅ Simpler to maintain (each class has one responsibility)

Base Classes

Here are the base classes I use:

Command (Write Operations)

/// Base class for commands that mutate state
abstract class Command<Params, Output> {
  const Command();

  FutureResult<Output> call(Params params);
}

/// Command without parameters
abstract class CommandNoParams<Output> {
  const CommandNoParams();

  FutureResult<Output> call();
}

Query (Read Operations)

/// Base class for queries that read data
abstract class Query<Params, Output> {
  const Query();

  FutureResult<Output> call(Params params);
}

/// Query without parameters
abstract class QueryNoParams<Output> {
  const QueryNoParams();

  FutureResult<Output> call();
}

Real Examples from My Auth Feature

Command: Login

Login is a Command because it mutates state by creating an authenticated session:

@injectable
class Login extends Command<AuthCredentials, User> {
  const Login(this._repository, this._eventDispatcher);

  final IAuthRepository _repository;
  final IEventDispatcher _eventDispatcher;

  @override
  FutureResult<User> call(AuthCredentials credentials) async {
    // Mutate state: authenticate user
    final result = await _repository.login(credentials);

    // Dispatch domain event on success
    return result.map((user) {
      _eventDispatcher.dispatch(UserLoggedIn(user));
      return user;
    });
  }
}

Query: CheckUserExists

CheckUserExists is a Query because it only reads data:

@injectable
class CheckUserExists extends Query<EmailAddress, bool> {
  const CheckUserExists(this._repository);

  final IAuthRepository _repository;

  @override
  FutureResult<bool> call(EmailAddress email) async {
    // Read-only: check if user exists
    return _repository.checkUserExists(email);
  }
}

Query: GetCurrentUser

@injectable
class GetCurrentUser extends QueryNoParams<User?> {
  const GetCurrentUser(this._repository, this._eventDispatcher);

  final IAuthRepository _repository;
  final IEventDispatcher _eventDispatcher;

  @override
  FutureResult<User?> call() async {
    // Read-only: get current user from cache/backend
    final result = await _repository.getCurrentUser();

    return result.map((user) {
      if (user != null) {
        _eventDispatcher.dispatch(UserSessionRestored(user));
      }
      return user;
    });
  }
}

Stream Variants

For reactive operations, I also have stream-based variants:

// Stream query - watch data changes
abstract class StreamQuery<Params, Output> {
  StreamResult<Output> call(Params params);
}

// Stream command - reactive write operations
abstract class StreamCommand<Params, Output> {
  StreamResult<Output> call(Params params);
}

Example: WatchAuthChanges is a StreamQueryNoParams<User?> that emits whenever the auth state changes.

How to Use in BLoC

class AuthBloc extends Bloc<AuthEvent, AuthState> {
  AuthBloc(this._login, this._checkUserExists, this._getCurrentUser);

  final Login _login;
  final CheckUserExists _checkUserExists;
  final GetCurrentUser _getCurrentUser;

  Future<void> _onSubmitCredentials(event, emit) async {
    // Use Command for login
    final result = await _login(AuthCredentials(
      email: event.email,
      password: event.password,
    ));

    result.fold(
      (failure) => emit(AuthState.error(failure)),
      (user) => emit(AuthState.authenticated(user)),
    );
  }

  Future<void> _onEmailSubmitted(event, emit) async {
    // Use Query for checking user
    final result = await _checkUserExists(event.email);

    result.fold(
      (failure) => emit(AuthState.error(failure)),
      (exists) => exists
        ? emit(AuthState.loginRequired(event.email))
        : emit(AuthState.registrationRequired(event.email)),
    );
  }
}

Benefits I've Seen

Clear Intent: Just by reading Login extends Command<...>, you know it mutates state
Testability: Queries are pure - same input = same output
SOLID Compliance: Each use case has a single responsibility
Discoverability: Team members can easily find all write vs read operations

Conclusion

CQRS isn't just for backend systems. In Flutter with Clean Architecture, it brings clarity and maintainability to your use case layer.

The key insight: Name your operations by what they DO, and type them by their NATURE (read vs write).

Follow @deveminsahin for more architecture patterns!

flutter #dart #cleanarchitecture #cqrs