[FEATURE] ember-testing-checkbox-helpers

[seanpdoyle]

Address concerns that helpers could behave differently than real users.

fixes #9798 (#9798 (comment))

When test driving, click and unclick are useful for ensuring the
state of a form.

export default DS.Model.extend({
  title: DS.attr(),
  body: DS.attr(),
  isDraft: DS.attr("boolean", defaultValue: false)
});

test("doesn't publish posts in draft mode", function() {
  fillIn("#title", "this post is hidden");
  fillIn("#body", "this won't be displayed");
  check("#is-draft");
  click("#submit");

  andThen(function() {
    equal(find(".post:contains('this post is hidden')").length, 0);
  });
});

check and uncheck allow the test to remain unchanged if the
defaultValue of isDraft changes from false to true.

The test only cares that:

• when click("#submit") executes, the #is-draft checkbox is checked
• isDraft is true

[seanpdoyle]

@tomdale addresses #9798 (comment)

[tomdale]

@seanpdoyle Seems legit, would you mind writing down somewhere the answer to the other question? I want to make sure we all have the same mental model.

Can we enumerate what use cases this is intended for? It's unclear why this is better than click(), other than it's slightly more expressive. The use cases should drive the semantics, which I think are incorrect right now. It's unclear to me why tests are ever so non-deterministic that you don't know whether a click turns it on or off in that particular test.

[rwjblue]

This needs to run through app.testHelpers.click. Something like app.testHelpers.click(selector, context).

[seanpdoyle]

@tomdale I've updated the commit message and PR body to provide an example use case

[rwjblue]

@seanpdoyle - Thanks for updating, we'll review this feature again for go/no-go (and potentially more work) at the next core team meeting.

[tomdale]

This feature has ended up being surprisingly controversial at the core team meetings. ;)

After a lengthy discussion, we reached consensus that, in the example you gave (defaultValue changing from false to true), we actually want the test to fail. While making code resilient to input is important, I think there's an important exception for test helpers; we should make them as explicit and fail-fast as possible.

We did reach consensus that we would like the check() and uncheck() helpers to be a combination of setting the value and asserting it becomes a specific value. In the case of check():

1. Before mutating the value, assert that the checkbox is unchecked.
2. Simulate a click event on the checkbox.
3. Assert that the checkbox has been checked (to catch, for example, the disabled case).

We believe that the above implementation strikes the best balance between explicitness and clarity, and expressiveness. What do you think?

[seanpdoyle]

@tomdale I like it.

Does this mean that the if blocks are replaced by book-ended Ember.assert calls?

[rwjblue]

@seanpdoyle - Yes, assert that it is unchecked before click is called, then assert that it is checked after click is called. And the same (in reverse) for unclick.