Managing Test User Module Data with MyBatis XML and Java Bean

Today I worked on managing the basic data of the test user module, encountering a tricky problem where user attributes are stored as id values that need to be converted to string types for the front‑end, while also handling numerous optional parameters and their validation.

The requirement diagram shows several filter conditions to retrieve the list of test users created by the current user, and the API documentation specifies that all parameters are required, with string defaults to an empty string and number defaults to 0 to indicate "all".

Below is the MyBatis XML mapper configuration that defines reusable SQL fragments and a complex select statement with conditional if clauses and a choose block to handle different query types (account, phone, or user ID).

<sql id="table">
    qa_test_user
</sql>

<sql id="user_status">
    qa_user_status_name
</sql>

<sql id="env">
    family_base_env
</sql>

<sql id="user_role">
    qa_role_name
</sql>

The corresponding Java bean, SearchUserBean , defines fields such as uid , envId , pagination parameters, role and status IDs, and validation annotations to ensure correct input ranges.

package com.okay.family.common.bean.testuser;

import com.okay.family.common.basedata.OkayConstant;
import com.okay.family.fun.base.bean.AbstractBean;
import org.hibernate.validator.constraints.Range;
import javax.validation.constraints.Min;

class SearchUserBean extends AbstractBean {
    private static final long serialVersionUID = 894894891651651L;

    int uid;
    @Range(min = 0L, max = OkayConstant.ENV, message = "环境参数错误")
    int envId;
    @Min(value = 1L)
    int pageNum;
    @Range(min = 5L, max = 20L, message = "每页显示数量设置错误")
    int pageSize;
    @Range(min = 0L, max = 10L, message = "用户身份参数错误")
    int roleId;
    @Range(min = 0L, max = OkayConstant.USER_STATUS, message = "用户状态参数错误")
    int status;
    String query;
    @Range(min = 0L, max = 2L, message = "搜索类型出错!0账号1手机号2用户id")
    int type;
}

Finally, the author reflects on the difficulty of making a small change that ripples through many places, hoping that fewer bugs will appear during testing.