Challenge 3: Choosing the Right Test Type — Solution

(a) NoteRepository's refresh() logic with a fake API
    -> UNIT TEST. This is pure logic (fetch, then write results) that
    can be fully exercised with a fake ApiService and fake/in-memory DAO
    implementation — no real Android framework, database, or network is
    genuinely needed to verify the logic is correct.

(b) Confirming a Button's click actually navigates to a new screen
    -> INSTRUMENTED / COMPOSE UI TEST. Navigation genuinely involves
    real Activity/Fragment/Compose-destination behavior (the Navigation
    Component from Course 1, or Compose navigation) that only exists
    when actually running on a device or emulator — there's no
    meaningful way to fake "did the screen actually change" at the pure
    JVM level.

(c) A pure Kotlin function calculating tax on a price
    -> UNIT TEST. This has zero Android framework dependency at all —
    it's a plain function taking a number and returning a number, the
    simplest and fastest possible case for a unit test, running in
    milliseconds on the JVM.

(d) Confirming a TextView's text updates after a ViewModel state change
    -> INSTRUMENTED TEST (Espresso, for the View system) or a COMPOSE UI
    TEST (if it's a Compose Text instead). This genuinely requires a
    real View/Compose node actually rendering on screen to verify
    against — the ViewModel's state logic itself could be unit tested
    separately, but confirming the UI actually reflects it needs a real
    rendering environment.

Notes:
- The general rule used throughout: if it's pure logic with no genuine
  Android framework/rendering dependency, it's a unit test candidate. If
  it requires an actual rendered UI, real click dispatch, or real
  navigation, it needs an instrumented/Compose UI test.
- (a) and (c) both being unit-test cases despite very different
  complexity levels illustrates the point: the deciding factor is
  "does this need the Android framework to actually run," not "how
  complex is the logic."