AppFUSE Learning Notes - Unit Test

xiaoxiao2021-03-06  17

APPFUSE provides a unit test for almost every class, which uses the JUnit framework for testing. We still take a closer analysis with user as an example. Before reading this article, you should have a concept that you should have a concept of unit testing. . 1. DAO Test UserDaOTest is used to test Userdao interface and its implementation USERDAOHIBERNATE, which is in TEST / DAO / ** / DAO /. All DAOTEST is inherited from BaseDaotestCase, BasedaTestCase inherits from Testcase. This parent class has written our way to load ApplicationContext from Spring. SETUP () made an initialization work before testing, created an instance of Userdao and Roledao, and TEARDOWN () made destruction work, this is what you have to do every JUnit test class. Take the testUpdateuser () method as an example, the method is mainly used to test whether the userdao's SaveUser () method is correct. First call GetUser () to obtain the information of the user "Tomcat", and modify its address, then call the SaveUser () method to save the modified record. Receive "Tomcat" information, check if the address is a new address, if the address is a new address, the test is successful. Next, set the value of "Tomcat" version of the Version property (Version to verify whether the current record is a new record, NULL represents a new record), re-saving "Tomcat", at this time, Hibernate will think that the record is new record, INSERT operation, but the username field is the main key. It should not be repeated, so an exception should be thrown. If you capture an exception, the test is successful. In the console enters the project root directory, type ant Test-dao -dtestcase = userdao, if build success, the test is successful. In this way, we don't need to write Manager, Action, JSP, and do not need to run the container. You can make sure our classes are correct.

2. Manager Test Next Continue to see the class UserManagerTestSt of UserManager. It in TEST / Service / ** / Service / inherits from BaseManagerTestCase, this parent class plays a similar role in the BaseDaOTestCase. Unlike UserDaotest, UserManagerTest uses JMock to help it test. JMock is used to solve the dependence of UserManager, because the userManager needs to call Userdao methods, and the basic rules of the unit test are only one object, JMock helps you get UserManager, so that it will not be affected by UserDao, let's see How do it do it. In Setup (), we put Userdao and Roledao in Mock, let Mock to do UserDao and Roledao agents, and inject these two "counterfeit" DAO into the UserManager. Still look at this Test class as an example. First create a User object, set the user name "tomcat", and the permissions are "User". Then we tell Mock When the userManager calls userDao's getUser () method is "Tomcat", we look forward to using Userdao to return to the object we just created. Next, call the clientManager's getUser () method to obtain "Tomcat" information. Modify the contents of the phone number. Then reset our requirements for MOCK. This time we are asked to return any values ​​when UserManager calls UserDao's SaveUser method. Then call the UserManager's SaveUser () method, check if the user is the new phone number and the permissions or one, if so, the test is successful. Verify () is used to check if all methods that should be called are called. Generally, each pair Mock object calls an expects (), and verify () is executed after use. Execute ant test-service -dtestcase = userManager in the console to see the results.

3. Action Test We continue to see the useerActiontest under TEST / Web / ** / Action. It inherits from BaseStrutstestCase, BaseStrutstestcase inherits MockStrutstestcase, which also made a job similar to BASEManagerTestCase. Action is a controller that is mainly used to receive a request for the view layer, call the model layer method, and then return to the view layer. Here we don't care about model layers or view layers, we only need to care about whether Action can properly obtain request and response requests, and can be turned correctly based on request. Mockstrutstestcase gave us a good support in this regard. Take TestSave () as an example, first create a userform, put some data in it, put the userform into the range corresponding to the action. Use the setRequestPathInfo () to set the request path to "/ saveuser", add the request parameters using addRequestParameter (), and the ActionPerform () method will simulate the entire process of request. Then use the verifyForward () method to verify that the request forwarding path is correct. And verify that USERFORM cannot be obtained in the Action range. Run Ant Test-Web -dtestcase = UserAction, OK. It should be aware that the unit test here is inherited from MockStrutStestcase, but does not use Mock, that is, it will actually execute all related methods, including modify the database. 4. JSP test We can also test JSP. Here is a tool called Canoo WebTest, which uses XML configuration to test JSP. Enter Test / Web /, there is a web-tests.xml file, there is a test of the PATH existing in all struts-config.xml. Take Saveuser Target as an example, we do a simple description. The test step is included in Steps, and INVOKE gives this STEP set one ID number, sets the requested URL: Editprofile.html. Next, verify that the Title of the JSP page is consistent with expected. The contents of {Webapp.prefix} and {userprofile.title} are defined in ApplicationResources in web-inf / classes. Next to the text domain in the form, use the ClickButton to click the save button to verify whether the saved page title is the expected title. This test needs to run the container, so you first run Tomcat, then type ant test-cano -dtestcase = Usertests or Ant TestsTSTS at the console to TOSTESTS. With Ant Run-all-tests without run Tomcat, Ant is doing this.

转载请注明原文地址:https://www.9cbs.com/read-41406.html

New Post(0)