Test view 'Tree View' - #692

@goneng It doesn't switch to "Tree view" any ideas ?

@hannesa2 Found it, and the xib change is not the problem.

self.app.segmentedControls[@"DetailTreeViewSwitcher"] can never match on macOS. There is no AX role that maps to XCUIElementTypeSegmentedControl on the Mac - that type exists for UISegmentedControl on iOS. The query compiles and runs, it just always comes back empty. The debug screenshot confirms the control is on screen with the first segment selected, so this is the query, not the app state.

I compiled your version of PBGitHistoryView.xib with ibtool and instantiated the nib in a throwaway Cocoa program to see what it actually produces:

NSSegmentedControl  accessibilityIdentifier=(nil)   <- the view exposes no AXIdentifier at all
  NSSegmentedCell   role=AXRadioGroup  ident=DetailTreeViewSwitcher
    SEG[0] role=AXRadioButton subrole=AXSegment value=1 help="Detailed View"
    SEG[1] role=AXRadioButton subrole=AXSegment value=0 help="Tree View"

Three things follow from that:

• The identifier lands on the cell, which is exactly the element the accessibility tree vends, so it does reach XCUITest. It is a radio group, not a segmented control.
• The segments are AXRadioButton, so viewSwitcher.buttons is empty as well. The next line would have failed even if the switcher had been found.
• The group's AXValue is the selected segment object, not an index, so [viewSwitcher.value isEqual:@1] would never be true. The 0/1 value lives on each segment.

One correction to the comment in the diff: self.app.segmentedControls.firstMatch was not resolving to the search prev/next control. It resolved to nothing, so the accessibility identifier was added to fix an ambiguity that was not there. Worth keeping the identifier anyway, but the queries have to change.

Two ways to fix it

Simplest - use the menu. Resources/en.lproj/MainMenu.xib:594 already wires View > Tree View to setTreeView: on the first responder with Command-Option-2 (Detail View is Command-Option-1). That matches how selectHistoryView and selectCommitView already work, and needs no element lookup at all:

- (void)selectTreeView {
    NSLog(@"[GitXScreenshotTests] Switching to the tree view with Command-Option-2");
    [self.app typeKey:@"2" modifierFlags:XCUIKeyModifierCommand | XCUIKeyModifierOption];
    [NSThread sleepForTimeInterval:0.5];
}

Or keep clicking the real control, so the screenshot also proves the switcher works. Keep the xib identifier and change the queries:

XCUIElement *viewSwitcher = self.app.radioGroups[@"DetailTreeViewSwitcher"];
...
XCUIElement *treeViewSegment = [viewSwitcher.radioButtons elementBoundByIndex:1];
[treeViewSegment click];
...
if (![treeViewSegment.value isEqual:@1]) { /* the click did not take */ }

Two things that will bite right afterwards

1. window.outlines.firstMatch is ambiguous in exactly the way you expected the segmented control to be. The window has two outline views: the sidebar (PBSidebarList, PBGitSidebarView.xib:31) and the file tree (PBQLOutlineView, PBGitHistoryView.xib:623). First match is very likely the sidebar, where the last row is a submodule rather than a file. Give the tree outline its own accessibility identifier the same way and query outlines[@"..."].

2. navigateToTreeViewAndSelectFile returning NO makes the test return without failing, so all four tree tests went green while doing nothing - which is why the runs are passing. For a test that has not worked yet, I would XCTFail on the not-found paths, at least until it is proven to run on CI.

Screenshot differs: emulatorApi=arm64 with 3 screenshot(s)

setpoint (old) | diff | actual screenshot (new)

commit-context-menu.png

scripts/Screenshots-arm64/debug-before-source-lookup.png (new screenshot)


scripts/Screenshots-arm64/tree-view.png (new screenshot)

@hannesa2 the PBGitWindowWiringTests hunk here is the same one as in
#519, and I think you can drop it from both: commitController being
nil in -historyListSelecting: is #703, which #702 fixed at the source
by turning PBShowStageView off in -setUp. More details in my comment
on #519.