Утверждать.assertEquals порядок параметров junit

1. правильная маркировка в инструментах / результаты сбоя - инструменты следуют этому порядку, и некоторые инструменты GUI будут помечать, какое значение является ожидаемым значением и какое значение является фактическим значением. По крайней мере, это минимизирует путаницу, если метки соответствуют значениям; в худшем случае вы тратите время / усилия на отслеживание неправильной проблемы, пытаясь проследить источник фактического значения, которое на самом деле не было фактическим значение.

2. согласованность в использовании assertEquals - если вы не последовательны в своем порядке во всех своих утверждениях, вы можете запутать future-you (или другого будущего сопровождающего), если значения произвольно меняются от случая к случаю, снова создавая потенциальную путаницу.

3. последовательное упорядочение параметров по методам assert - это может быть обратимым для assertEquals, но порядок может иметь значение для другие методы assert* (во встроенных файлах JUnit и в других поддерживающих кодах/библиотеках). Лучше быть последовательным во всем.

4. изменения в будущем - наконец, может быть разница в будущей реализации.

5. *технические* - его ожидаемое значение equals метод, который используется:

есть одна тонкая разница после просмотра кода. Многие из применений assertEquals () в конечном итоге будут выполняться с помощью этого метода:

115 static public void assertEquals(String message, Object expected,
116         Object actual) {
117     if (expected == null && actual == null)
118         return;
119     if (expected != null && isEquals(expected, actual))
120         return;
...
128
129 private static boolean isEquals(Object expected, Object actual) {
130     return expected.equals(actual);
131 }

его equals метод ожидаемого значения, которое используется, когда оба объекта являются ненулевыми. Можно утверждать, что вы знаете класс ожидаемого значения (и, следовательно, знаете поведение equals метод класса ожидаемого значения), но вы можете не обязательно знать наверняка класс фактического значения (который теоретически может иметь более разрешительный equals метод). Следовательно, вы может получить другой результат, если вы поменяете два аргумента (т. е. два разных класса' equals методы не рефлексивные друг друга):

надуманный случай будет ожидаемым значением ArrayList и фактическим значением, которое может возвращать любой тип экземпляра коллекции, возможно, ArrayList, но также, возможно, экземпляр пользовательского класса коллекции без списка " Foo "(т. е. Foo не реализует List). Коллекции это equals метод (на самом деле его AbstractList.equals) указывает:

возвращает true, если и только если указанный объект является также список, как списки имеют одинаковый размер, и все соответствующие пары элементов в два списка равны.

возможно, класс "Фу"equals метод является более разрешительным, указывая:

возвращает true тогда и только тогда, когда указанный объект также является коллекцией коллекции имеют одинаковый размер, и обе коллекции содержат одинаковые объекты но не обязательно в том же порядке.

словами:

ArrayList expectArrayList = ...;
Collection actualCollectionPossiblyFoo = ...
Assert.assertEquals(expectedArrayList, actualCollectionPossiblyFoo)

вы говорите, что ожидаете чего-то эквивалентного ArrayList (согласно определению ArrayList/AbstractList equals). Это потерпит неудачу, если actualCollectionPossiblyFoo - это действительно класс Foo и таким образом не List as требуется ArrayList equals метод.

ArrayList expectedArrayList = ...;
Collection actualCollectionPossiblyFoo = ...;
Assert.assertEquals(actualCollectionPossiblyFoo, expectedArrayList);

, потому что actualCollectionPossbilyFoo может быть экземпляром Foo и Фу может считать себя и expectedArrayList равными по Foo класса equals метод.