Configuring failure output for ExUnit?

[Conrad Taylor]

Hi, is there way to programmatically change the failure output to use 'expect' and 'actual' instead of lhs and hrs?  For example,

1) test the truth (SampleTest)

   test/sample_test.exs:4

   Assertion with == failed

   code:    1 + 1 == 3

   actual:  2

   expect: 3

   stacktrace:

     test/sample_test.exs:5

Well, I must go and thanks in advance for any information that you can provide.

-Conrad

[Eric Meadows-Jönsson]

There is no way to configure it. May I ask why you want to change it?

“actual” and “expect” will be weird when the operands are reversed:

1) test the truth (SampleTest)
   test/sample_test.exs:4
   Assertion with == failed
   code:   3 == 1 + 1
   actual: 3
   expect: 2
   stacktrace:
     test/sample_test.exs:5

​

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Eric Meadows-Jönsson

[Conrad Taylor]

Hi, it's simply much clearer to me when using words instead of acronyms like rhs and lhs. Furthermore, 'code' and 'stacktrace' are much clearer to me than using 'cd' and 'st' respectively.  In short, I would like the proper naming in code to be also applied to the naming of reports like this one.

--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/yAHoeTBB27Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Think different and code well,

-Conrad

[Eric Meadows-Jönsson]

But like I showed “actual” and “expected” are not the correct names. For the assertion assert x == y which is operand is the expected value, x or y?

I agree that full names are more descriptive than abbreviations, but in my opinion “left hand side” is simply too long compared to “lhs”. What “lhs” and “rhs” means is also quite clear from context.

​

[Conrad Taylor]

Hi, 'lhs' and 'rhs' specify a positions but it doesn't say which side is in error.  Is the right side correct and left side wrong or is the left side correct and the write side wrong?  When I run this sample test, they both appear as red.  Please see the attachment.  In short, 'lhs' and 'rhs' has positional information but no information as to which happens to be in error.

[Conrad Taylor]

I meant to send this attachment.

[Mike Chmielewski]

I think that's a feature, not a bug. I've seen developers put the expected on either side of the assertion in test frameworks in the past. So why bother biasing the display output?

[Alexei Sholik]

The result shows the code. So when you write

  assert expected == my_func()

it will show

Assertion with == failed

code: expected == my_func()   <---

lhs:    2

rhs:    3

You can see which thing is expected (lhs here) and which one is computed (rhs here).

Maybe "left" and "right" would be more easily distinguishable?

Best regards
Alexei Sholik

[Conrad Taylor]

Alexei, I understand the flow of the test and the resulting report that’s being generated.  However, I don’ t understand the following:

1)  The convention for writing unit tests.

    Is it  

    assert expected == actual

    Or is it

    assert actual == expected

    Or does it matter and just be consistent within a single project or application?

2)  lhs and rhs doesn't provide enough value in the context of the unit test.  However, I believe the following would be clearer to the reader:

assertion: 2 == my_function failed

 expected: 2

   actual: 3

or something 

assertion: 2 == my_function failed

 expected: 2

      got: 3

I’ll play with this a while before I submit a pull request and/or formal proposal.  Just something to consider in the future because I spend my time tutoring and I know from experience that students will pose these and other questions.  Next, I’m truly enjoying the language and I look forward to what’s to come in the future.

—

[Eduardo Gurgel]

Related:

https://github.com/elixir-lang/elixir/pull/2080

https://github.com/elixir-lang/elixir/pull/2082

So it was kind of recently that we decided for the current format.

I prefer the way it's now. You don't need to have any convention and the difference is clear.

My 2 cents,

Eduardo

Eduardo

[Peter Hamilton]

Some historical context on assert: traditionally assert takes a boolean and halts the flow of execution of it is not true. The common error you might see is "expected: true, actual: false" which is hardly helpful.

The wonderful assert in ExUnit decomposes the syntax tree so that it can show lhs, rhs, and the operator. Yay Macros!

Anyway, if the assert in ExUnit doesn't do what you want, why not just create a new macro? If you want clear position conventions, something like the following might make sense:

should_equal/2

should_equal(2, 3)

-or-

2 |> should_equal 3

Output:
Expected: 3
Actual: 2

Just my 20 öre.

[Alexei Sholik]

I could never remember myself whether expected value should go on the left or on the right when ExUnit used to call them something like "expected" and "actual". Then it switched to "lhs" and "rhs" and now I don't have to remember anything. I think the change was good.

Often you can use match (=) instead of comparison (==). With match it is obvious that the expected value goes on the left.

[José Valim]

I could never remember myself whether expected value should go on the left or on the right when ExUnit used to call them something like "expected" and "actual".

You could have used this flow chart:

                            

              |- No  -> assert 1 + 1 == 2

Are you Yoda? |

              |- Yes -> assert 2 == 1 + 1

:)

[Dave Thomas]

Except Yoda doesn't need tests—he issues them....

--

[Augie De Blieck Jr.]

On days like this, I REALLY love this list...

-Augie

[Jim Freeze]

I love the lhs and the rhs descriptions.

I never liked it when arbitrary meanings were applied to expressions based on their relative positions to ==.

For english speaking folks, lhs and rhs are very clear. Of course, someone could create a better symbol that the three letter acronym.  However, I imagine it would be perfectly clear except for one possible use case

lhs=1; rhs=2;

assert rhs == lhs

Assertion with == failed

code: rhs == lhs

lhs: 2

rhs: 1

On Thu, Jul 10, 2014 at 11:50 AM, José Valim <jose....@plataformatec.com.br> wrote:

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Jim Freeze