Repository navigation
assert: order of expected and actual params #399
Description
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")Reacted by Luiz Cezer, Alexandre Pesant, Dennis O'Harlem, Alex, Ben Schumacher, Matthias L., Ernesto Alejo, Pierre Peltier, ty, Ecem Unal and 21 more
Activity
joonas-fi commentedon Feb 26, 2017
I totally agree, this is a dealbreaker for me. Golang ain't Java, and we don't need or want "yoda conditions".
mvdkleijn commentedon Apr 7, 2020
Related to #146 but I for one think this is a good point. It's a major breaking change though.
brackendawson commentedon Feb 1, 2024
Duplicate of #146