Implement non-end-to-end acceptance testing with spring

Acceptance testing allows the delivery team to go beyond the basic continuous integration, verifying that the application provides valuable functionality for the user. But for a team that is just beginning to try to deploy the pipeline, the three hurdles need to be crossed to automate acceptance testing.

The first is to realize and maintain the technical threshold of acceptance testing. Ideally, acceptance testing might be a good way to simulate a user's real interaction with the application, so if there is a graphical interface, acceptance testing should be done through the interface and the system. However, the direct testing through the GUI will encounter several problems: the interface changes quickly, the preparation of the scene is relatively complex, to get the test results more difficult. For example, a typical Web application, if the GUI test, then the general need to parse the HTML tag to fill out the parameters, submit the form, and finally again through the resolution to obtain the system's return value. If the test code is full of details of manipulating HTML, the test will be much less readable and the acceptance test itself will be more vulnerable, slowing progress as the requirements change.

The second is the change of working mode of the delivery team. In a traditional team, requirements analysis, development, and testing are independent and sequential processes. Even if a detailed requirement document is formed, the three parties may have their own understanding of the same piece of text. The results are often skewed, and demand analysts complain that developers do not understand the requirements document correctly, and developers complain that the requirements are unclear and that testers are complaining. The emergence of agile practices and acceptance tests alleviates this problem by defining acceptance specifications, reducing textual misunderstandings, and defining the completion criteria for development work. However, this change of mindset is difficult to achieve overnight, and needs to be delivered to the team and its stakeholders in a sustained effort to succeed.

The third is the challenge to the organization's environment, configuration management and deployment process. When automated acceptance testing is introduced, there is a higher level of automation for the entire deployment pipeline. For example, the deployment pipeline should be able to automatically deploy the application to a test-ready environment. If your application relies on a database, you should also be able to deploy the database schema. Other Run-time configurations also require scripting to complete the setup. In addition to scripting preparation, the organization's environmental management is also to be able to keep up. Typically, a slightly larger organization has a dedicated operational team (rather than a delivery team) to manage hardware devices and their configuration. Therefore, this problem generally involves several teams to work together to solve.

Faced with these three mountains and progress pressure, the novice team may feel "a little bit of information" and stalled. Then you may consider each and all the changes in the working methods of the three issues involve the largest number of stakeholders and the most difficult; environmental management issues, although involved in different teams, but generally or technical department problems, close the door to negotiate; The implementation/maintenance of acceptance test is mainly technical problem, relatively simplest. If time and resources are really limited, consider sacrificing some of the validation of acceptance tests, and using simple, end-to-end acceptance testing, you can also make some compromises in automating the deployment process, concentrating on changing the way you work. When the whole work has entered the rhythm, then to improve a specific link is much smoother. The team can also get a lot of value if they are willing to take a small step.

Transition scenario: Relatively simple non-end-to-end acceptance testing

If the technical accumulation of the team is not sufficient, and there is not enough resources, we might consider a simple acceptance test strategy as a transitional solution. Non-end-to-end acceptance testing is the direct invocation of the internal logic structure of the application to drive the test. Since both the test code and the product code are written in the same language, the cumbersome data format parsing can be omitted. When preparing test data and scenarios, it is generally more convenient to call internal logic blocks directly. As an example of a typical Java Web application using Springframework, a team can write a non-end-to-end acceptance test using an infrastructure similar to the integration test.

The purpose of the integration test described here is to verify that the connection between the application and the external service works correctly. This has little to do with the specific functionality that the application implements, so typically only the required ApplicationContext are loaded.

Chart 1 set into a test