Testing strategies — unit, widget, integration

Testing to inwestycja. Dla MVP: nie testuj wszystkiego, ale testuj critical paths. Flutter ma 3 typy testów: unit, widget, integration.

Testing Pyramid

Unit tests (70%):

• Testują pojedyncze funkcje/klasy
• Szybkie (< 1ms per test)
• Tanie w utrzymaniu
• Najwięcej testów powinno być unit

Widget tests (20%):

• Testują UI components
• Średnio szybkie (~10ms per test)
• Testują interakcje (tap, scroll)

Integration tests (10%):

• Testują cały flow (end-to-end)
• Wolne (sekundy per test)
• Drogie w utrzymaniu
• Tylko critical paths

Unit Tests (Flutter)

Co testować:

• Business logic (use cases, services)
• Data transformations
• Validation logic
• State management (providers, blocs)

Czego NIE testować:

• Getters/setters
• Framework code (Flutter widgets)
• Third-party libraries

Mocking: Użyj mockito do mockowania dependencies (API, database)

Widget Tests

Co testować:

• Widget renderuje się poprawnie
• Tap/scroll działa
• State changes aktualizują UI
• Error states wyświetlają się

Przykład: Test login screen

• Renderuje email i password fields
• Tap "Login" wywołuje callback
• Error message wyświetla się gdy login fails

Integration Tests

Co testować:

• Happy path (login → dashboard → action)
• Critical flows (checkout, payment)
• Cross-platform (iOS, Android, Web)

Narzędzia:

• Flutter integration_test package
• Patrol (lepszy niż integration_test)
• Maestro (no-code mobile testing)

Test Coverage

Cel dla MVP:

• Business logic: 80%+
• UI: 50%+
• Overall: 60%+

Nie gonić 100% — diminishing returns. Focus na critical code.

TDD (Test-Driven Development)

Red-Green-Refactor:

• Red: Napisz test (fails)
• Green: Napisz kod (test passes)
• Refactor: Popraw kod

Dla MVP: TDD dla critical logic. Reszta: testy po implementacji.

Best Practices

• Fast tests: Cały suite < 30 sekund
• Isolated: Każdy test niezależny
• Deterministic: Zawsze ten sam rezultat
• Readable: Test = dokumentacja
• AAA pattern: Arrange, Act, Assert