-2

Jasmine expect statements can produce worthless error messages like:

 Expected true to be false.

To address this, matchers allow you to add a clarifying message as a second argument, expectationFailedOutput:

toBe(expected: any, expectationFailOutput?: any): Promise<void>;

This allows you to write:

expect(await password.isDisplayed).toBe(true, "Password field should be visible");
expect(await password.isDisplayed).toBe(true, "Password field was not visible");

These will produce the following error messages, respectively:

Expected false to be true, 'Password field should be visible'.
Expected false to be true, 'Password field was not visible'.

Note, that these lines are the same except that in the first case, I described what the expect was testing for, and in the second, I describe what actually happened.

Obviously, I should choose one these conventions and use it consistently in my code base, but I can't find anything in the documentation about what the typical convention is. Should the message describe what we expected to happen, or should it describe what did happen?

If the Jasmine team doesn't have a convention for this, perhaps somebody who's worked on a lot of Jasmine projects knows what the typical convention is.

cnishina
  • 5,016
  • 1
  • 23
  • 40
Mud
  • 28,277
  • 11
  • 59
  • 92
  • I do not know if that's helpful at all but we go for the first variant in our Java & JUnit-based tests. We also try to formulate our assert messages in a way the used convention is clearly communicated. For example, for the given example we would go with assert message 'Expected visible password field'. – Michal Feb 11 '19 at 19:59
  • Both points are helpful, thanks. – Mud Feb 11 '19 at 21:47

1 Answers1

-1

I don't see why it should be consistent and why it obviously. Some checks are easy to understand, some hard. When you feel that you need message - add it. Don't make it hard when it could be simple.

Oleksii
  • 1,623
  • 20
  • 26
  • You didn't understand the question. It wasn't whether I should add a clarifying message. The question was: if I add a clarifying message, should it describe what I was expecting, or what actually happened. These are opposite of each other. e.g. if I say expect(x).toEqual(y), I could describe this as 'x should equal y', so the error messages says what I expect to happen, or I could say "x does not equal y", so the error message says what is actually happening. I need to use one or the other consistently, because otherwise the error messages are harder to interpret. – Mud Feb 11 '19 at 16:42