# First Build, Test And Commit

> Create your first safe checkpoint before moving on to the architecture.

- URL: https://dantech.academy/en/courses/kotlin-accelerator/engineer-builder/00-setup-app-running/lesson-05-first-build-test-commit
- Course: [Mobile Action Pro](https://dantech.academy/en/courses/kotlin-accelerator.md)
- Module: Setup App Running
- Duration: 12 min
- Difficulty: beginner
- Access: Free, full lesson
- Tiếng Việt: https://dantech.academy/courses/kotlin-accelerator/engineer-builder/00-setup-app-running/lesson-05-first-build-test-commit.md

## Objectives

- Build the Android app and run the test suite with the exact CI command: testDebugUnitTest plus testAndroidHostTest
- Change the text on the shared Splash screen through Compose Resources and understand LocaleParityTest
- Create a first safe Git commit as a "known good" checkpoint

---

## Lesson Goal

This lesson creates your first checkpoint: the app builds, the test suite passes, the app launches once, you change one line of text on the Splash screen, and Git holds exactly one safe commit.

## Why This Checkpoint Matters

Reading architecture is much easier once the app runs. Without this checkpoint, every later error is ambiguous:

- Did an architecture change break something?
- Was the project never configured correctly?
- Is a local secret missing?
- Is Gradle failing because of the environment?

The checkpoint gives you a "known good" point in time. When something breaks, you compare against it instead of guessing.

## Part 1: Build The Android App

Open the repo in Android Studio. After sync finishes, click the hammer icon at the top right to build.

Or run this from Android Studio's `Terminal` tab at the repo root:

```bash
./gradlew assembleDebug
```

In the Windows Command Prompt, type `gradlew assembleDebug`. The command passes when it ends with `BUILD SUCCESSFUL`.

## Part 2: Run The Test Suite

Tests tell you that you haven't broken an existing feature while building a new one. Run:

```bash
./gradlew testDebugUnitTest testAndroidHostTest
```

This is also the command the repo's CI runs on every pull request (`.github/workflows/pr-check.yml`). It passes when it ends with `BUILD SUCCESSFUL`.

Why two tasks? Of the 14 Gradle modules, only `:app` is a plain Android module. The other 13 are Kotlin Multiplatform, and their tests don't run under the `testDebugUnitTest` task:

| Task                  | Runs the tests of                                                             |
| --------------------- | ----------------------------------------------------------------------------- |
| `testDebugUnitTest`   | `:app` only                                                                   |
| `testAndroidHostTest` | The KMP modules: `commonTest` and `androidHostTest`, on your machine's JVM    |

If you only run `testDebugUnitTest`, Gradle reports green while most of the suite never ran. You will meet this trap in every KMP project: the task names you know from plain Android no longer cover the shared code. When you pick up a new KMP project, confirm which test task actually reaches each module before you trust the green.

Tests of the KMP modules on the iOS Simulator only run on a Mac, through the `iosSimulatorArm64Test` task.

## Part 3: Run The App Once

Pick an emulator or a real phone in the Android Studio toolbar and click Run. Wait until the app gets past the Splash screen and into the Menu.

## Part 4: Make One Small Visible Change

Your first commit proves you can change one small detail, check it, and save it safely. Don't refactor a screen, rename a package or change navigation.

The line of text under the logo on the Splash screen is drawn by the `SplashScreen` composable, in:

```text
shared-app/src/commonMain/kotlin/com/creative/kta/shared/splash/SplashScreen.kt
```

The file sits in `commonMain`, so Android and iOS draw the same screen. The text comes from the `knowledge_is_power` string resource through Compose Resources (`Res.string.knowledge_is_power`). Change this string's value in two files:

```text
core/src/commonMain/composeResources/values/strings.xml
core/src/commonMain/composeResources/values-vi/strings.xml
```

The `values` file is used when the device is set to English, `values-vi` when it is set to Vietnamese. The Vietnamese text must differ from the English one: `LocaleParityTest` (which runs in `:app`'s `testDebugUnitTest`) fails if a Vietnamese string is identical to the English one, or if a key has no `values-vi` entry.

The repo also has `knowledge_is_power` in `app/src/main/res/values/strings.xml`. That's an Android resource, and the Splash screen doesn't read it. Edit it there and nothing changes.

Run the tests from Part 2 again, run the app again and confirm the Splash screen shows the new text.

## Part 5: Create A Safe Git Checkpoint

```bash
git status
git add core/src/commonMain/composeResources/values/strings.xml core/src/commonMain/composeResources/values-vi/strings.xml
git commit -m "Change splash tagline"
```

Read `git status` carefully before you commit. The modified list should only show the two strings files you just edited. `local.properties` and `app/google-services.json` don't show up because they are ignored.

## Checkpoint

You are done with this lesson when:

- `./gradlew assembleDebug` and `./gradlew testDebugUnitTest testAndroidHostTest` both end with `BUILD SUCCESSFUL`,
- The Splash screen shows the new text in both English and Vietnamese,
- `git log -1` shows your commit, and the commit holds only the two strings files.

The app builds, the tests are green and you have a first commit on Android. That's the checkpoint you come back to whenever a later change breaks the build.

---

- Previous lesson: [Set Up Supabase SQL, Secrets And Firebase](https://dantech.academy/en/courses/kotlin-accelerator/engineer-builder/00-setup-app-running/lesson-04-configure-local-files-secrets.md)
- Next lesson: [Run The App On iOS (macOS + Xcode)](https://dantech.academy/en/courses/kotlin-accelerator/engineer-builder/00-setup-app-running/lesson-06-run-app-on-ios.md)