Add Grid editor support to GridTester

Open
  • Is something wrong?
#262 2 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
java, kotlin
Domain
testing

Research direction

Start with GridTester and the Kotlin Editor._editItem(item) in shared/src/main/kotlin/com/vaadin/browserless/component/Grid.kt; compare the renderer lookup behavior of getCellComponent and the existing GridProTester API. Resolve the buffered, unbuffered, dynamic-component, and validation-failure semantics before implementing the proposed editor operations. Done means tests can open an editor, reach its bound components, save or cancel, and assert refused saves.

Written by the indexing model from the issue text.

Description

Problem. The Grid row editor (Grid.getEditor()) has no tester support. A
test can open a view that uses the editor, but there is no way to drive it:

var grid = new GridTester<>(component);
grid.doubleClickRow(0);   // the app's listener may open the editor...
// ...and from here there is nothing: no isEditorOpen(), no way to reach the
// editor's fields, no saveEditor() / cancelEditor()

So the whole "user double-clicks a row, edits the fields, saves (or cancels),
the row shows the new values" flow — the reason the editor exists — cannot be
expressed.

What exists today

  • GridProTester.setValue(row, column, value) covers GridPro's inline
    editing. That is a different component with a different interaction model and
    does not help with the plain Grid editor.
  • The Kotlin layer has Editor<T>._editItem(item) in
    shared/src/main/kotlin/com/vaadin/browserless/component/Grid.kt, which calls
    editItem(item) and then does a client round trip. Nothing calls it and no
    tester exposes it, so it is unreachable from a test as things stand.
  • doubleClickRow(row) already fires ItemDoubleClickEvent, so an application
    that wires addItemDoubleClickListener to editor.editItem(...) does get the
    editor opened today. The gap is everything after that point.

Sketch of the missing API on GridTester:

  • editRow(int row) — open the editor for a row
  • isEditorOpen() and the item currently being edited
  • getEditorComponent(int column) / getEditorComponent(String columnKey) —
    the live field component of the open editor
  • saveEditor() / cancelEditor()

Points that need deciding before implementing

  • Grid.Column.getEditorComponent() only returns the statically set component.
    When a column uses setEditorComponent(SerializableFunction<T, Component>)
    the component is produced per item, so the tester has to hand back the
    instance actually bound for the edited item — the same problem
    getCellComponent already solves for renderers.
  • Buffered vs unbuffered editors behave differently on save, so what
    saveEditor() means in each mode has to be pinned down.
  • A save can be refused by editor.getBinder() validation. The failed
    validation path is exactly what tests want to assert, so it should surface as
    something assertable rather than a silently ignored save.
  • Following the convention used by the rest of the testers ("fail if the user
    could not have done this"), editRow should presumably fail when the grid has
    no editor binder, and interacting with a closed editor should fail rather than
    silently do nothing.

Split out of #175, whose deselect part shipped in #187.

Dominant language
Java
Stars
1
Forks
3
Avg merge
1d 19h
Merged PRs (30d)
15

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from vaadin/browserless-test

All issues in vaadin/browserless-test

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.