Test-driven development (TDD) is actually not a new concept, but the essence of this methodology is often misunderstood. In my case, I think test-driven development means writing unit tests to fully test the code. In fact, this is one of the most common misunderstandings about test-driven development. Test-driven development not only emphasizes testing, but also emphasizes drive development. The purpose of writing test cases is not only testing, but also a design, a design of functions and interfaces, and a design from the perspective of users of functions or interfaces, while the design in other methodologies is Design from a developer's perspective, so test-driven development is more conducive to producing good designs.
But just designing through testing and running tests to ensure code quality is not enough to produce high-quality software products. Test-driven development also emphasizes refactoring, which is to refactor the unreasonable parts of the code, and this refactoring needs to be carried out during every test writing, development, and verification process. Since there are test cases to guarantee it, we can be confident and bold Refactor without worrying about unintended consequences.
Back to our project, in MainServlet, we implemented all business logic, but we will soon realize that if all application logic is written into this class, that class will become If it becomes a giant, it will eventually become unmaintainable, so we need to put the user registration business logic implementation into the user module. As you can see, we have begun to reconstruct our system.
First, we create the user package and create the UserMngr class under this package because we estimate that in addition to maintaining basic user information, the user module also needs to maintain user groups, user levels, user points and other information. It is not necessary for the caller to fully understand these details, so we use the Facade mode here, and all operations on the user are performed through UserMngr. The code is as follows:
public class UserMngr { public static long registerUser(Map<String, Object> userInfo) { return 101; } }
We see that in this class, we only return a value and do nothing, in order to quickly verify that our reconstructed architecture can work and the specific functions can To be added later. In addition, you need to pay attention to the parameter items. The Map object is used here, that is, the parameters are passed in an array similar to PHP. It is more common in Java to design a value object class for this purpose, but this often results in defining many value object classes, or due to the need for sharing, a value object is very large. Here, Map is used to pass parameters, which eliminates the need for such trouble.
Add the code to call the user module in MainServlet below:
private void registerUser(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String userName = null; if (request.getParameter("userName") != null) { userName = request.getParameter("userName"); } Map<String, Object> userInfo = new HashMap<String, Object>(); userInfo.put("userName", userName); long userId = UserMngr.registerUser(userInfo); Map<String, Object> model = new HashMap<String, Object>(); model.put("userId", "" + userId); request.setAttribute("model", model); /*this.getServletContext().getRequestDispatcher("/caporder/apply_capital.jsp") .forward(request, response);*/ }
Run the test case below and it should pass. This proves that my reconstruction of the architecture is successful this time.
The above is the content of the New Java Movement: Test Driven Development 3---User Registration 2. For more related content, please pay attention to the PHP Chinese website (m.sbmmt.com)!