thông số Assert.assertEquals junit đặt

Question

Thứ tự của các tham số cho Assert.assertEquals phương pháp trong JUnit là (expected, actual)

Mặc dù trong một thread ai đó nói rằng là không có lý do, một trong các lớp Java của tôi trong Uni vị giáo sư đề cập đến một cụ thể lý do của việc đặt hàng đó, nhưng tôi không nhớ nó.

Bất kỳ ai cũng có thể giúp tôi với điều này?

Answer 1

1. ghi nhãn đúng trong các công cụ/thất bại kết quả - Các công cụ đang theo dõi thứ tự này và một số công cụ GUI sẽ dán nhãn mà giá trị là giá trị kỳ vọng và giá trị nào là giá trị thực tế. Ít nhất, nó sẽ giảm thiểu sự nhầm lẫn nếu các nhãn phù hợp với các giá trị; tồi tệ nhất, bạn dành thời gian/công sức theo dõi vấn đề sai cố gắng theo dõi nguồn của giá trị thực tế không thực sự là giá trị thực.

2. nhất quán trên assertEquals sử dụng - Nếu bạn không phù hợp theo thứ tự của bạn trong suốt khẳng định, bạn có thể nhầm lẫn tương lai bạn (hoặc duy trì trong tương lai khác) nếu giá trị này được hoán đổi tùy tiện từ trường để hợp cụ thể, một lần nữa cho vay để có thể nhầm lẫn.

3. đặt hàng Phù hợp tham số qua các phương pháp khẳng định - Nó có thể đảo ngược cho assertEquals, nhưng thứ tự có thể có vấn đề cho các phương pháp khẳng định * khác (trong xây dựng-in JUnit và trong việc hỗ trợ mã/libs khác). Tốt hơn là nhất quán trên tất cả.

4. Thay đổi trong tương lai - Cuối cùng, có thể có sự khác biệt trong việc triển khai trong tương lai.

5. * kỹ thuật * - Phương pháp equals giá trị kỳ vọng của nó được sử dụng:

Có một sự khác biệt tinh tế sau khi xem xét các mã. Nhiều người trong số những ứng dụng của assertEquals() sẽ kết thúc chạy qua phương pháp này:

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 } 

của các equals phương pháp giá trị dự kiến ​​được sử dụng khi cả hai đối tượng đều là phòng không null. Người ta có thể lập luận rằng bạn biết lớp của giá trị kỳ vọng (và do đó biết hành vi của phương pháp equals của lớp giá trị kỳ vọng) nhưng bạn có thể không nhất thiết phải biết chắc chắn lớp học của giá trị thực tế (mà theo lý thuyết có thể có nhiều hơn permissive equals phương pháp). Do đó, bạn có thể có được một kết quả khác nhau nếu bạn thay đổi hai đối số (tức là equals phương pháp hai lớp khác nhau là không phản nhau):

Một trường hợp giả tạo sẽ là một giá trị kỳ vọng của một ArrayList và một giá trị thực tế có thể trả về bất kỳ loại cá thể Bộ sưu tập nào, có thể là một ArrayList, nhưng cũng có thể là một cá thể của một lớp không phải Danh sách tùy chỉnh 'Foo' (ví dụ:Foo không thực hiện List). Phương pháp này của ArrayList equals (trên thực tế nó AbstractList.equals) quy định cụ thể:

trả về true khi và chỉ khi các đối tượng quy định cũng là một danh sách, cả hai danh sách có cùng kích thước, và tất cả các cặp tương ứng của các nguyên tố trong hai danh sách bằng nhau.

Có lẽ phương pháp equals 'Foo' lớp là dễ dãi hơn đó nêu rõ:

trả về true khi và chỉ khi các đối tượng quy định cũng là một bộ sưu tập, cả hai bộ sưu tập có cùng kích thước, và cả hai bộ sưu tập chứa đối tượng bằng nhau nhưng không nhất thiết phải theo cùng một thứ tự.

Bằng cách nói:

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

bạn đang nói bạn mong đợi một cái gì đó tương đương với một ArrayList (theo định nghĩa của equals ArrayList/AbstractList của). Điều này sẽ thất bại nếu actualCollectionPossiblyFoo thực sự thuộc loại Foo và do đó không phải là List là theo yêu cầu của phương pháp ArrayList equals.

Tuy nhiên, điều này không giống như nói:

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

vì actualCollectionPossbilyFoo có thể là một thể hiện của Foo và Foo có thể xem xét bản thân và expectedArrayList được bình đẳng theo Foo phương pháp equals lớp của.

Answer 2

Không có lý do cụ thể. Họ có thể đã ra lệnh cho các thông số của họ theo cách khác. BTW, TestNG hiện nó the other way.

Đối với khả năng đọc tốt hơn và expressibility, tôi thích sử dụng khẳng định thông thạo với fest-assert