PHP code reconstruction

As PHP changes from a simple scripting language to a mature programming language, the complexity of a typical PHP application code library increases. To control the support and maintenance of these applications, we can use various testing tools to automate the process. One of them is... "/> <scripttype =" text/javascript "src =" http://www.2ct As PHP changes from a simple scripting language to a mature programming language, the complexity of a typical PHP application code library increases. To control the support and maintenance of these applications, we can use various testing tools to automate the process. One of them is unit testing, which allows you to directly test the correctness of the written code. However, the legacy code library is generally not suitable for such tests. This article describes how to refactor PHP code that contains frequently asked questions, so as to simplify the testing process using popular unit test tools and reduce the dependence on the improved code library. Looking back at the development history of PHP over the past 15 years, we found that it has changed from a simple dynamic scripting language used to replace the popular CGI script to a mature modern programming language. As the code library grows, manual testing has become an impossible task. large or small, changes in code will affect the entire application. These effects may be as small as they only affect the loading of a page or the storage of forms. They may also cause problems that are difficult to detect or generate errors that only occur under specific conditions. Even, it may cause previously fixed problems to reappear in the application. Therefore, many testing tools have been developed to solve these problems. One of the popular methods is the so-called function or acceptance test, which tests the application through typical user interaction of the application. This is a method that is suitable for testing various processes in an application. However, the testing process may be very slow and it is generally impossible to test whether the underlying classes and methods work properly as required. In this case, we need to use another test method, namely unit test. The purpose of unit testing is to test the underlying code functions of an application and ensure that they produce correct results after execution. In general, these "increasing" Web applications will gradually become more and more legacy code that is difficult to test over time, making it difficult for the development team to ensure the coverage of application testing. This is often called "untestable code ". Now let's take a look at how to identify untestable code in an application and how to fix it. Identifying untestable code issues concerning the untestable nature of the code library is not obvious when writing code. When writing PHP application code, people tend to write code according to the Web request process, which is usually a more streamlined method in application design. Eager to complete the project or quickly fix the application may prompt developers to "take shortcuts" to quickly complete coding. In the past, improper or confusing code may aggravate the non-testable problem in the application, because developers often fix the problem with minimal risk, even if it may cause subsequent support problems. These problem domains cannot be found through general unit tests. Global variables dependent on the global state function are very convenient in PHP applications. They allow you to initialize some variables or objects in the application and then use them elsewhere in the application. However, this flexibility comes at a cost, and excessive use of global variables is a common problem that cannot be tested. We can see this in listing 1. Listing 1. Global-dependent functions Results = $ dbconn-> query ('select name from mytable');} public function getFirstResult () {return $ this-> results [0];} here, to test the fdfdfd method of the object, we need to establish a database connection, add some records to the table, and then clear all these resources after the test. If the fdfdfd test does not require these items at all, the process may be too complicated. Therefore, we need to modify the constructor shown in listing 6. Listing 6. classes modified to ignore unnecessary initialization logic Init ();} public function init () {$ dbconn = new DatabaseConnection ('localhost', 'user', 'password '); $ this-> results = $ dbconn-> query ('select name from mytable');} public function getFirstResult () {return $ this-> results [0];} we have reconstructed a large amount of code in the constructor and moved them to an init () method. by default, this method is still called by the constructor to avoid disrupting the logic of the existing code. However, during the test, only one boolean value false can be passed to the constructor to avoid calling the init () method and all unnecessary initialization logic. Class refactoring also improves the code, because we separate the initialization logic from the object's constructor. As described in the previous section, the hard-coded class dependencies cause a large number of class design problems caused by testing difficulties to be concentrated on initializing various objects that do not need to be tested. Previously, we knew that the heavy initialization of the issue series could put a lot of burden on writing the test (especially when the test completely does not need these objects ), however, if we directly create these objects in the Test class method, another problem may occur. Listing 7 shows the sample code that may cause this problem. Listing 7. initialize the class of another object directly in one method Query ('select name from user'); sort ($ results); return $ results ;}} suppose we are testing the getUserList method above, however, our test focus is to ensure that the returned user list is sorted alphabetically. In this case, the question is not whether these records can be obtained from the database, because we want to test whether we can sort the returned Records. The problem is that because we instantiate a database connection object in this method, we need to perform all these tedious operations to test the method. Therefore, we need to modify the method so that this object can be inserted in the middle, as shown in listing 8. Listing 8. This class has a method that will directly instantiate another object, but it also provides an override method. Query ('select name from user'); sort ($ results); return $ results ;}} now you can directly input an object that is compatible with the expected database connection object, use this object directly instead of creating a new object. You can also input a simulated object, that is, in some calling methods, the desired value is directly returned in hard-coded mode. Here, we can simulate the query method of the database connection object, so that we only need to return the results without actually querying the database. This method can also be improved when such refactoring is performed, because it allows your application to insert different database connections as needed, rather than binding only one specified default database connection. The benefit of testable code is clearly that writing more testable code can certainly simplify unit tests for PHP applications (as you can see in the example shown in this article ), however, in this process, it can also improve the design, modularization and stability of applications. We have seen the "spaghetti" code, which is filled with a lot of business and performance logic in a major process of a PHP application, this will undoubtedly cause serious support problems for those who use this application. In the process of making the code more testable, we have reconstructed some of the previous problematic code, which is not only problematic in design but also functional. By making these functions and classes more widely used, and by removing hard-coded dependencies, we make them easier to be reused by other parts of the application, and we improve code reusability. In addition, we will replace poorly written code with better code to simplify future support for the code library. Conclusion in this article, we learned how to improve the testability of PHP code through some typical untestable code examples in PHP applications. We also introduced how these situations occur in the application, and then introduced how to properly fix these problems to facilitate testing. We also learned that the modifications to these codes not only improve the code testability, but also improve the quality of the code and the reusability of the restructured code.