orderPRO/.paul/phases/07-pre-expansion-fixes/07-04-PLAN.md

---
phase: 07-pre-expansion-fixes
plan: 04
type: tdd
wave: 2
depends_on: []
files_modified:
  - tests/Unit/AllegroTokenManagerTest.php
  - tests/Unit/AllegroOrderImportServiceTest.php
autonomous: true
---

<objective>
## Goal
Dodać testy jednostkowe dla dwóch krytycznych ścieżek: logiki odświeżania tokenów OAuth (AllegroTokenManager) i happy path importu zamówień Allegro (AllegroOrderImportService). PHPUnit jest już skonfigurowany — testy muszą przejść `vendor/bin/phpunit`.

## Purpose
AllegroTokenManager zawiera złożone edge case'y (token expired, refresh token empty, write-then-re-read) które są krytyczne dla działania wszystkich integracji Allegro. Bez testów każda zmiana w okolicach token managementu jest ryzykowna. AllegroOrderImportService importSingleOrder() ma catch(Throwable) w kilku miejscach — bez testów błędy mogą być swallowane po cichu.

## Output
- `tests/Unit/AllegroTokenManagerTest.php` — 5+ testów pokrywających logikę tokenów
- `tests/Unit/AllegroOrderImportServiceTest.php` — 3+ testy happy path + jedna ścieżka błędu
</objective>

<context>
## Project Context
@.paul/PROJECT.md

## Source Files
@src/Modules/Settings/AllegroTokenManager.php
@src/Modules/Settings/AllegroOrderImportService.php
@tests/bootstrap.php
@phpunit.xml
</context>

<acceptance_criteria>

## AC-1: AllegroTokenManager — logika refresh pokryta testami
```gherkin
Given AllegroTokenManager zarządza tokenami OAuth z logiką: odśwież jeśli wygaśnie w ciągu 5 min
When testy jednostkowe są uruchamiane przez PHPUnit
Then istnieje test dla: token świeży (brak refresh)
  AND test dla: token wygasły lub wygaśnie za < 5 min (refresh triggered)
  AND test dla: brak refresh token (oczekiwany wyjątek lub ok:false)
  AND wszystkie testy przechodzą: vendor/bin/phpunit tests/Unit/AllegroTokenManagerTest.php
```

## AC-2: AllegroOrderImportService — import happy path pokryty
```gherkin
Given AllegroOrderImportService::importSingleOrder() pobiera zamówienie i zapisuje je do DB
When testy jednostkowe są uruchamiane
Then istnieje test dla: import sukces (pełne zamówienie ze wszystkimi polami)
  AND test dla: import zwraca dane zamówienia (assert na kluczowe pola odpowiedzi)
  AND testy nie uderzają w prawdziwą bazę ani API (mocki/stubs)
  AND testy przechodzą: vendor/bin/phpunit tests/Unit/AllegroOrderImportServiceTest.php
```

## AC-3: Wszystkie nowe testy przechodzą
```gherkin
Given nowe pliki testowe istnieją w tests/Unit/
When uruchamiasz vendor/bin/phpunit
Then zero FAILURES, zero ERRORS dla nowych test files
```

</acceptance_criteria>

<tasks>

<task type="auto">
  <name>Task 1: Testy dla AllegroTokenManager</name>
  <files>
    tests/Unit/AllegroTokenManagerTest.php,
    src/Modules/Settings/AllegroTokenManager.php
  </files>
  <action>
    Przeczytaj `src/Modules/Settings/AllegroTokenManager.php` dokładnie.
    Zrozum: konstruktor, zależności, logika `resolveToken()`, kiedy refresh jest wywoływany.

    Stwórz `tests/Unit/AllegroTokenManagerTest.php`:
    ```php
    <?php
    declare(strict_types=1);

    namespace Tests\Unit;

    use PHPUnit\Framework\TestCase;
    use PHPUnit\Framework\MockObject\MockObject;
    // Dodaj odpowiednie use statements dla AllegroTokenManager i jego zależności
    ```

    Wymagane scenariusze testowe (co najmniej):
    1. **Token świeży** — expires_at > now + 5min → resolveToken() zwraca token bez refresh
    2. **Token wygaśnie za < 5 min** — expires_at < now + 300s → resolveToken() wywołuje refresh
    3. **Token już wygasły** — expires_at < now → resolveToken() wywołuje refresh
    4. **Brak refresh token** — token wygasły, refresh_token pusty → oczekiwany wyjątek lub failure signal
    5. **Write-then-re-read** — po refresh, token jest odczytany z repo (nie z odpowiedzi API)

    Używaj PHPUnit Mock Objects dla zależności (AllegroOAuthClient, repository).
    Sprawdź które dependency injection AllegroTokenManager przyjmuje w konstruktorze.
    Mockuj zewnętrzne zależności — testy NIE mogą uderzać w Allegro API ani DB.

    Stosuj `setUp()` żeby nie powtarzać kodu inicjalizacyjnego.
  </action>
  <verify>
    php -l tests/Unit/AllegroTokenManagerTest.php
    vendor/bin/phpunit tests/Unit/AllegroTokenManagerTest.php --testdox
  </verify>
  <done>AC-1 i AC-3 satisfied: 5+ testów AllegroTokenManager, wszystkie zielone</done>
</task>

<task type="auto">
  <name>Task 2: Testy dla AllegroOrderImportService</name>
  <files>
    tests/Unit/AllegroOrderImportServiceTest.php,
    src/Modules/Settings/AllegroOrderImportService.php
  </files>
  <action>
    Przeczytaj `src/Modules/Settings/AllegroOrderImportService.php` dokładnie.
    Zidentyfikuj: zależności konstruktora, `importSingleOrder()` flow, co zwraca.

    Stwórz `tests/Unit/AllegroOrderImportServiceTest.php`.

    Wymagane scenariusze (co najmniej):
    1. **Happy path** — API zwraca poprawne zamówienie → importSingleOrder() zwraca sukces
       - Mock AllegroApiClient który zwraca fixture z polami zamówienia
       - Assert że wynik zawiera ['ok' => true] lub odpowiednik sukcesu
       - Assert że OrdersRepository::upsert (lub odpowiednia metoda) była wywołana
    2. **401 retry** — jeśli importSingleOrder() ma logikę retry przy 401 → test że retry jest wywoływany
    3. **API error** — AllegroApiClient rzuca wyjątek → importSingleOrder() zwraca ['ok' => false]
       lub propaguje wyjątek (sprawdź aktualną semantykę)

    Uwaga na catch(Throwable) bloki — sprawdź czy są testowane i czy swallują w sposób
    widoczny (logowanie) czy całkowicie cichy. Jeśli całkowicie cichy — zanotuj w SUMMARY.

    Używaj fixture danych (tablica PHP) dla response API — nie potrzebujesz realnej struktury
    API, wystarczy minimum wymagane przez metodę mapującą.
  </action>
  <verify>
    php -l tests/Unit/AllegroOrderImportServiceTest.php
    vendor/bin/phpunit tests/Unit/AllegroOrderImportServiceTest.php --testdox
  </verify>
  <done>AC-2 i AC-3 satisfied: 3+ testów AllegroOrderImportService, wszystkie zielone</done>
</task>

</tasks>

<boundaries>

## DO NOT CHANGE
- Logika produkcyjna AllegroTokenManager i AllegroOrderImportService — tylko testy
- Istniejące pliki w tests/ — bootstrap.php, inne pliki Unit (jeśli istnieją)
- phpunit.xml — nie modyfikuj konfiguracji, tylko dodaj nowe pliki testowe

## SCOPE LIMITS
- Tylko testy jednostkowe z mockami — bez testów integracyjnych z realnym DB/API
- Nie dodawaj testów dla innych klas poza AllegroTokenManager i AllegroOrderImportService
- Jeśli zależności są trudne do mockowania — użyj minimalnego zestawu testów (happy path + 1 error path)
- ShopproOrdersSyncService — nie w tym planie

</boundaries>

<verification>
Przed zamknięciem planu:
- [ ] php -l tests/Unit/AllegroTokenManagerTest.php
- [ ] php -l tests/Unit/AllegroOrderImportServiceTest.php
- [ ] vendor/bin/phpunit tests/Unit/ — zero FAILURES, zero ERRORS
- [ ] AllegroTokenManagerTest.php: min. 4 metody testowe
- [ ] AllegroOrderImportServiceTest.php: min. 3 metody testowe
</verification>

<success_criteria>
- tests/Unit/AllegroTokenManagerTest.php: 5+ testów, zielone
- tests/Unit/AllegroOrderImportServiceTest.php: 3+ testów, zielone
- vendor/bin/phpunit --testdox: czyste wyjście dla obu plików
</success_criteria>

<output>
Po zakończeniu utwórz `.paul/phases/07-pre-expansion-fixes/07-04-SUMMARY.md`
</output>