Java Theory and Practice: balancing Test, part 3rd: Using aspects to test design constraints

Aspect-oriented programming (AOP) is a promising new technology, but the adoption of new technologies can be risky (and, of course, there is a risk of not adopting new technologies). As with all new technologies, it is usually best to follow a path that can manage risk. If you use AOP to execute policies and tests, you get the benefit of mitigating risk from AOP. Because the aspect does not go into production, there is no risk of technology breaking code stability or the development process, but it will help to develop better quality software. Testing with aspects is also a good way to learn how to work and experience this exciting new technology.

Combined test method

As I discussed in part 1th, the purpose of QA is not to find all the bug--that are possible because it is impossible--but to elevate our confidence in how the code works as expected. The challenge for managing an effective QA organization is to maximize the return on the resources it spends, that is, the degree of certainty. Because all of the test methods will eventually show a return on the payoff (for an equal amount of pay increase, getting true reliability is increasing and less), and different methods are suitable for finding different types of errors, so it is better to spread QA effort into testing, code review and static analysis than to spend the entire QA budget on one of these measures. The rewards are better.

Static analysis tools such as FindBugs are imprecise, but imprecise analysis is still very useful and effective for improving the quality of the software. They may emit false warnings, such as triggering warnings on harmless constructs, or ignoring bugs, such as not finding all bugs that match a particular bug pattern. But they still find real bugs, and as long as the false positives are not high enough to annoy the user, they still provide a valuable reward for the cost of the test.

From a test standpoint, there is much in common with using AOP to validate design rules and to use static analysis. Static analysis and aspect-oriented programming do not design test cases for specific methods or classes, but encourage the identification of all categories that violate the rules and create artifacts capable of discovering any irregularities in the code body. Another similarity is that they do not have to be perfect or useful; Although bugs detectors or tests do not find all possible bugs, and some even emit false warnings, they are still very helpful tools to verify that the code works as expected. Some bug patterns are easier to find with static tools, while others are easier to find-making the aspect a useful way to participate in the QA process.

A simple test aspect

FindBugs such static analysis tools audit the code but do not execute the code, and aspect-oriented tools provide both static and dynamic-class tools. Static aspects can generate compile-time warnings or errors, and dynamic aspects can insert error detection code into the class.

In the 1th part, I provide a simple FindBugs probe that looks for calls to System.GC () that might lurk in the library. Many bug patterns that can be detected by static analysis (including this pattern) can also be detected by the aspect; depending on the specific bug pattern, it may be easier to do static analysis or use, so putting them all in the tool library can improve the effect.

Listing 1 shows a simple dynamic aspect that throws a assertionerror when the System.GC () is invoked. (because one of the important roles of such bug detectors is not only to find errors in your own code, but also to find errors in the libraries that your code relies on, you might want to tell the tool to analyze or process the libraries.) ）

Listing 1. To perform the dynamic aspect of the "Do not Invoke System.GC ()" Rule

public　 aspect　GcAspect　{
　　 pointcut　gcCalls()　:　call(void　java.lang.System.gc ());

　　 before()　:　gcCalls()　{
　　　　 throw　new　AssertionError("Don't　call　System.gc!");
　　 }
}

Listing 1 shows a dynamic approach that is not as effective as testing with static analysis because it requires the program to actually perform a call to System.GC () before it discovers the problem, rather than having a program that contains only one call to System.GC (), which is detected. However, it will soon be seen that dynamic aspects are more flexible because they can execute arbitrary test code on the point at which they are triggered, thus providing finer control over the declared problem.

You can also easily create a static aspect that recognizes the call to System.GC () at compile time, as shown in Listing 2. Similarly, if you want to discover the bug pattern that appears in the library code, not only do you want to work with the code in the project, but also the libraries it uses.

Listing 2. To perform a static aspect of the "Do not Invoke System.GC ()" Rule

public　 aspect　StaticGcAspect　{
　　 pointcut　gcCalls()　:　call(void　java.lang.System.gc ());

　　 declare　error　:　gcCalls()　:　"Don't　call　System.gc!";
}