assert: order of expected and actual params

[kostyantyn]

It's rather a question than an issue.

What is the reason that assert.* functions receive first expected value and then actual?
For instance: assert.Equal(t, 5, count) instead of assert.Equal(t, count, 5)

We can compare this example with if condition.
It's more natural to read if count == 5 than if 5 == count.

Another point to accept an actual param first is that it's easier to spot which fields get checked in a test because usually actual param is a variable but expected is a constant. For instance:

asssert.Equal(t, "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor", title)
asssert.Equal(t, "Ut enim ad minim veniam, quis nostrud exercitation ullamco", description)

vs

asssert.Equal(t, title, "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor")
asssert.Equal(t, description, "Ut enim ad minim veniam, quis nostrud exercitation ullamco")

[joonas-fi]

I totally agree, this is a dealbreaker for me. Golang ain't Java, and we don't need or want "yoda conditions".

[mvdkleijn]

Related to #146 but I for one think this is a good point. It's a major breaking change though.

[brackendawson]

Duplicate of #146