Shulou(Shulou.com)06/01 Report--

This article mainly introduces "the solution of testing PHP code function coverage on the web side". In the daily operation, I believe that many people have doubts about the solution of testing PHP code function coverage on the web side. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "Web side testing PHP code function coverage solution". Next, please follow the editor to study!

1. About code coverage

There are many levels to measure code coverage, such as line coverage, function / method coverage, class coverage, branch coverage, and so on. Code coverage is also an important measure of test quality. for black-box testing, if you are not sure whether your test case really runs through every line of code in the system, there will always be a discount on the integrity of the test. Therefore, the industry almost has its own set of code coverage solutions for all kinds of programming languages. PHP, the most beautiful language in the world, is no exception. PHPUnit and Spike PHPCoverage provide a set of code coverage testing solutions based on xdebug. In this article, I will talk about my solution for testing the coverage of PHP code functions for the specific business scenarios I encounter.

two。 Business background

Suppose we develop a website online and give it to our business testing colleagues for functional testing. So how did they test it? Usually, the developer deploys the site, and then the tester tries out all the features on the web, including some unusual usage. For business testing, as long as I measure all the function points and all exception usage, it's done. But for developers, what I'm curious about is, have you run all the code I've written? Is there some code that can only be triggered in very special circumstances that you have never detected? At this point, code coverage may be needed.

In fact, I first thought of xdebug to test coverage, which only takes two or three functions, as follows:

Xdebug_start_code_coverage (); / / start collecting line coverage xdebug_get_code_coverage (); / / get the code file name and line number xdebug_stop_code_coverage () that have been run so far; / / stop collecting line coverage

The interface provided by xdebug can be used to test line coverage. Does this meet the requirements? In fact, the granularity of line coverage is a little fine, and in actual projects, developers may fine-tune the code. For example, in this test, you ran past line 10 of the A.php file, but one day I fine-tuned A.php, adding two more lines of code between lines 9 and 10 of A.php. As a result, the original line 10 becomes line 12, and xdebug's line override information records only the line number. Isn't the data before this not accurate? On second thought, I think function coverage is a good granularity. In relatively mature projects, there are few large-scale function changes. The problem, however, is that xdebug does not provide an interface for function coverage.

So, the scene we're dealing with now is:

[1] you want to test the list of all the functions covered in a test, know how many functions there are in this project, and calculate whether the coverage is high enough.

[2] after the test is complete, generate a coverage report to visualize the coverage of the code.

[3] the process of complete testing is as follows:

Stake insertion means some preparatory work before the test is executed.

3. The principle of function coverage solution (1)

Xdebug naturally provides support for line coverage, so we have to calculate the function coverage ourselves. Function coverage requires two points of data, one is which functions are executed, and the other is how many functions are in the file.

The total number of functions in the file, since it is impossible for us to execute all the functions at once, this part can only be achieved by static scanning of the code. If you are in C++ or Java, you may need lexical analysis tools, but in the face of the most beautiful language, PHP, we don't need to be that complicated at all. Starting from PHP4.3, tokenizer is built into PHP Zend Engine to help developers do source code lexical analysis. We only need to find the lexical rules corresponding to the functions defined in PHP, and we can easily get all the functions in the specified PHP file.

The interface defined by tokenizer is also very simple:

Array token_get_all (string $source)

This function parses the file and splits the php source code into an array of token.

String token_name (int $token)

Converts an token in integer form to a string form. Similar to the strerror function in C language. With tokenizer, a finite state machine is designed according to the law and format defined by the php function, and the analysis of the full function can be completed.

Another difficulty in finding function coverage is to get a list of functions that are executed. This place made us take some detours. The easiest way to start is that now that we get the held line through xdebug, we can use the line number to reverse which function the line belongs to. However, the amount of line number information obtained by each request is very large. If a plea executes 1000 lines, it will be judged 1000 times, which will be relatively inefficient. After some research, it is found that xdebug provides the function of function trace, which can get the function call relationship in a request, but can not get the file where it is located, but get the function name. So, do some research again and find that Reflection, given the method name and class name, can be inferred in which file it is defined. So we use function trace to temporarily store the function call relationship in a temporary file, and then through file parsing, get the name of the executed function (in the case of a class method, in the form of "class name:: function name"), and then deduce the file that defines the function through the reflection mechanism. I once again realized the power of the most beautiful language in the world.

(2) inserting piles

In order to reduce the barrier to use, it is better to change the PHP source code as little as possible. Xdebug collects information by calling xdebug_start_code_coverage and xdebug_stop_code_coverage respectively to control the beginning and end of coverage information collection, so it is inevitable to change the source code. Our solution here is to register xdebug_stop_code_coverage through register_shutdown_function as a program that must be run before the end of the php program (similar to the C language atexit function), package it into a file, and then require this file on the first line of the source code. If your PHP framework is CodeIgniter, all requests have a unified entry index.php framework, then only need to change this file, only one line of changes to the source code! In fact, almost all current PHP frameworks use an index.php file as the entry for all requests.

The only change we made to the source code was the addition of a sentence in the first line of the entry file index.php:

The core code logic of phpcoverage.php is roughly as follows:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.