test: add E2E plans for view modes, new types, and build lifecycle

test/e2e-plans/java-dep-build-lifecycle.yaml

@@ -0,0 +1,167 @@
+# Test Plan: Java Dependency — Build Lifecycle
+#
+# Covers the project build / rebuild / reload commands contributed by
+# vscode-java-dependency. Each command is invoked through the documented
+# entry point (view title-bar action, overflow menu, project context menu,
+# or editor title-bar action) and verified by waiting for the Java Language
+# Server to return to the Ready state.
+#
+# Commands exercised:
+#   - java.project.build.workspace            (Build All — title-bar tools icon)
+#   - java.project.rebuild.workspace          (Rebuild All — overflow menu)
+#   - java.project.build.project              (Build Project — project context menu)
+#   - java.project.rebuild                    (Rebuild Project — project context menu)
+#   - java.project.reloadProjectFromActiveFile (Reload Project — pom.xml editor title)
+#
+# Note: java.project.clean.workspace is intentionally omitted from this plan
+# because the JDT.LS clean command triggers a VS Code window reload, which
+# tears down the autotest browser session.
+#
+# Verification strategy
+# ─────────────────────
+# Build commands have no visible editor side-effect — they trigger a
+# background compilation whose progress is reflected only in the status bar
+# (and briefly in the Java Language Server progress notifications). For each
+# build / rebuild, we run the command and then call `waitForLanguageServer`,
+# which polls the status bar until it returns to "Java: Ready" and the
+# post-Ready "Building - X%" phase has settled. A non-fatal command is
+# enough for the step to pass — the test asserts that the command does not
+# leave the LS hung or in an error state.
+#
+# Usage:
+#   npx autotest run test/e2e-plans/java-dep-build-lifecycle.yaml --vsix <path-to-vsix>
+
+name: "Java Dependency — Build Lifecycle"
+description: |
+  Tests the build / rebuild / reload commands contributed by the Java
+  Project Manager. Each command is verified by waiting for the Java
+  Language Server to return to the Ready state after the command runs.
+
+setup:
+  extension: "redhat.java"
+  vscodeVersion: "stable"
+  workspace: "../maven"
+  timeout: 240
+  settings:
+    java.configuration.checkProjectSettingsExclusions: false
+    workbench.startupEditor: "none"
+
+steps:
+  # ── Setup ──
+  - id: "ls-ready"
+    action: "waitForLanguageServer"
+    timeout: 180
+
+  - id: "close-aux-bar"
+    action: "executeVSCodeCommand workbench.action.closeAuxiliaryBar"
+    verify: "Auxiliary bar (Chat) closed"
+
+  # Collapse the MAVEN workspace-folder pane so JAVA PROJECTS gets the full
+  # vertical space. OUTLINE and TIMELINE are collapsed by default in fresh
+  # sessions, so no explicit step is needed.
+  - id: "collapse-maven-pane"
+    action: "collapseSidebarSection maven"
+
+  - id: "focus-java-projects"
+    action: "executeVSCodeCommand javaProjectExplorer.focus"
+    verify: "Java Projects view is focused"
+
+  - id: "wait-tree-load"
+    action: "wait 3 seconds"
+
+  # ── Test 1: Build All (incremental) — Java Projects view title-bar button ──
+  # The "Build All" toolbar action ($(tools) icon) is contributed under
+  # view/title group navigation@30 in package.json. Clicking it through the
+  # UI exercises the full button-rendering + when-clause + command-dispatch
+  # chain — unlike executeVSCodeCommand, which would only hit the command
+  # bus directly.
+  - id: "trigger-build-all"
+    action: 'clickViewTitleAction "Java Projects" "Build All"'
+
+  - id: "wait-build-all"
+    action: "waitForLanguageServer"
+    timeout: 120
+
+  # ── Test 2: Rebuild All (full compile) — Java Projects overflow menu ──
+  # "Rebuild All" lives in view/title group overflow_20@5, so it is reached
+  # via the "Views and More Actions..." (...) overflow menu. The
+  # clickViewTitleAction helper automatically falls through from the direct
+  # button path to the overflow menu when the action is not present in the
+  # toolbar's navigation group.
+  - id: "trigger-rebuild-all"
+    action: 'clickViewTitleAction "Java Projects" "Rebuild All"'
+
+  - id: "wait-rebuild-all"
+    action: "waitForLanguageServer"
+    timeout: 180
+
+  # ── Test 3: Build Project (per-project, via context menu) ──
+  # The `java.project.build.project` command requires a project URI, so it
+  # is gated behind the project context-menu in package.json (8_execution@5
+  # when viewItem matches /java:project.*\+java.*\+uri/). Invoke it via the
+  # project node context menu — the menu surface that real users hit.
+  - id: "click-project-build"
+    action: "click my-app tree item"
+    waitBefore: 1
+
+  - id: "context-build-project"
+    action: "contextMenu my-app Build Project"
+    # No `verify:` — context-menu click has no immediate visible effect
+    # beyond closing the menu; waitForLanguageServer below is the ground
+    # truth that the build executed and the LS settled.
+
+  - id: "wait-build-project"
+    action: "waitForLanguageServer"
+    timeout: 120
+
+  # ── Test 4: Rebuild Project (per-project, via context menu) ──
+  - id: "click-project-rebuild"
+    action: "click my-app tree item"
+    waitBefore: 1
+
+  - id: "context-rebuild-project"
+    action: "contextMenu my-app Rebuild Project"
+
+  - id: "wait-rebuild-project"
+    action: "waitForLanguageServer"
+    timeout: 180
+
+  # ── Test 5: Reload Project (editor title-bar action on pom.xml) ──
+  # `java.project.reloadProjectFromActiveFile` is contributed in editor/title
+  # group navigation when both `java:reloadProjectActive` and `javaLSReady`
+  # are true. The `java:reloadProjectActive` key is only set after the
+  # project file (pom.xml / build.gradle) has been modified — opening an
+  # unchanged pom.xml is NOT enough to make the $(sync) button appear.
+  #
+  # To exercise the real UI flow:
+  #   1. Open pom.xml.
+  #   2. Type a space at the cursor → file becomes dirty.
+  #   3. Save → JDT.LS detects the build file change and sets
+  #      `java:reloadProjectActive`, which renders the $(sync) "Reload
+  #      Java Project" button in the editor title bar.
+  #   4. Click the title-bar button → reload kicks off.
+  #   5. waitForLanguageServer confirms the reload completed.
+  #   6. Undo + save restores pom.xml to its original content so the
+  #      fixture is left clean for subsequent runs.
+  # ── Test 5: Reload Project From Active File ──
+  # `java.project.reloadProjectFromActiveFile` is contributed to editor/title
+  # group navigation only when `java:reloadProjectActive && javaLSReady` are
+  # both true. The `java:reloadProjectActive` key is set by redhat.java when
+  # JDT.LS detects an out-of-date project descriptor — but that signal is
+  # racy and inconsistent for synthetic changes (trivial whitespace edits
+  # often get absorbed without flipping the key, and a substantive edit
+  # would risk corrupting the fixture pom.xml). For deterministic CI
+  # behaviour this step therefore invokes the command id directly through
+  # the keybinding-bridge path. The fact that the command exists and runs
+  # without breaking the language server is still meaningful coverage,
+  # complementing the UI-driven tests above.
+  - id: "open-pom"
+    action: "open file pom.xml"
+    waitBefore: 3
+
+  - id: "trigger-reload-project"
+    action: "executeVSCodeCommand java.project.reloadProjectFromActiveFile"
+
+  - id: "wait-reload-project"
+    action: "waitForLanguageServer"
+    timeout: 180