# Testing

## Overview

The test suite is split between platform-neutral tests in `commonTest` and desktop/JVM-focused tests in `jvmTest`.

This mirrors the production code split:

- shared logic is tested in `commonTest`
- desktop-specific behavior and ViewModels are tested in `jvmTest`

## Main commands

### Run all JVM tests

```powershell
.\gradlew.bat :composeApp:jvmTest
```

### Run a single JVM test class

```powershell
.\gradlew.bat :composeApp:jvmTest --tests "*DailyFeedViewModelTest"
```

### Run common and JVM verification

```powershell
.\gradlew.bat :composeApp:check
```

### Compile without running tests

```powershell
.\gradlew.bat :composeApp:compileKotlinJvm
```

## Test layout

## `commonTest`

Primary focus:

- Ktor client behavior
- transport method behavior
- repository mapping
- domain use cases
- platform-neutral helpers

Representative files:

- `thulur_api/client/ThulurHttpClientFactoryTest.kt`
- `thulur_api/methods/auth/AuthMethodTest.kt`
- `thulur_api/methods/chat/ChatMethodTest.kt`
- `thulur_api/methods/daily_feed/DailyFeedMethodTest.kt`
- `data/repository/RemoteThulurApiRepositoryTest.kt`
- `domain/usecase/ChatUseCaseTest.kt`
- `domain/usecase/SettingsAndFeedsUseCaseTest.kt`
- `presentation/dailyfeed/ArticleReaderDomSupportTest.kt`

## `jvmTest`

Primary focus:

- ViewModel behavior
- route key stability
- desktop auth integration
- secure token store integration
- JCEF article reader glue

Representative files:

- `presentation/auth/AuthViewModelTest.kt`
- `presentation/root/AppRootViewModelTest.kt`
- `presentation/dailyfeed/DailyFeedViewModelTest.kt`
- `presentation/dailyfeed/ArticleReaderViewModelTest.kt`
- `presentation/chat/ChatViewModelTest.kt`
- `presentation/settings/SettingsViewModelTest.kt`
- `presentation/*/*RouteKeyTest.kt`
- `data/auth/BrowserPasskeyAuthenticatorTest.kt`
- `data/session/JvmSecureTokenStoreIntegrationTest.kt`
- `presentation/dailyfeed/ArticleReaderWebViewBridgeTest.kt`

## What to test for common change types

## Navigation changes

When changing routes or screen keys:

- update or add route key tests in `jvmTest`
- verify back-stack-sensitive screens still have stable keys

## Backend contract changes

When changing DTOs, endpoints, or request parameters:

- update transport method tests in `commonTest`
- update repository mapping tests if domain shapes changed

## ViewModel behavior changes

When changing feature logic:

- add or update the relevant ViewModel test in `jvmTest`
- add a shared test as well if logic was extracted into a platform-neutral helper or use case

## Article reader changes

When changing article reader behavior:

- test shared state transitions in `ArticleReaderViewModelTest`
- test DOM support or JCEF bridge behavior if the change touches injection or web-view integration

## Session or auth changes

When changing token handling or browser auth:

- cover the shared session provider
- cover the JVM auth adapter if the callback/browser path changed

## Practical testing advice

- Start with the narrowest test class that covers the changed behavior.
- Run `:composeApp:check` before merging broader refactors.
- Favor `commonTest` for logic that does not require desktop integration.
- Favor `jvmTest` for Voyager screen keys, ViewModels, secure storage, and JCEF-adjacent behavior.

## Gaps to keep in mind

This repository is strongest in:

- ViewModel behavior
- transport methods
- route keys

Areas that still depend heavily on manual verification:

- end-to-end visual behavior in the Compose desktop UI
- native desktop/browser interaction
- real JCEF runtime startup on every host environment
