This article briefly summarizes how I designed interface test cases.

Today, when I was reviewing the code for my colleague, I found that his code omitted some scene processing, so I talked with him more about this topic.

Here we assume an interface design as follows:

UserInfoDTO listUserInfoByUserIds(UserInfoQueryParam param);
Copy the code

UserInfoQueryParam is defined as follows:

Public class UserInfoQueryParam {// omits serialization ID List<Long> userIds; / /... Omit other fields}Copy the code

Boundary value test

This approach is generally used to test the robustness of an interface; For the userIds attribute, I build the following test case:

  1. userIds=null
  2. userIds=EmptyList
  3. The size of userIds is equal to the specified value of the batch interface
  4. The size of userIds is larger than the size limit of the batch interface
  5. Elements in userIds can be null
  6. The case where all elements in userIds are null
  7. The element in userIds has 0 (or negative) cases
  8. The case where all elements in userIds are zero (or negative)

Combined condition test

This method is generally used to test whether the business processing logic in different situations conforms to expectations. In this example, userIds may have two types, but our interface needs to support both types, so the test case design is as follows:

  1. Pure type 1 data in userIds
  2. Pure type 2 data in userIds
  3. A mixture of data of type 1 and type 2 in userIds

This is how I think about building a test case for an interface, and I welcome your discussion.