Contracts for pragmatic code analysis

[ArsenHD]

Here are some thoughts and ideas from discussion with @Damtev and @dtim .

This topic is for future discussions of how we could use contracts to improve UtBot code analysis.

A couple examples:

• In case the contract tells us that a certain field of class is always initialized with a specific value and never changes, we can be sure that we can rely on this value in our analysis. Even more important contract here is the one telling that a field is initialized with no "unsafe" operations. By "unsafe" here we mean operations like accessing environment variables or reading the file system. Such contracts are especially useful when dealing with fields of functional interface types:

class A {
    final Predicate<String> somePredicate = (str) -> str.length < 10;
    
    ...
}

In this case we know the value of the field somePredicate for certain. Since it is a lambda, we can actually work with it in the generated test code (although via reflection). In case we weren't sure about a value of the somePredicate field, we would have to use mocking to initialize this field, because we do not know what else to initialize it with (except for arbitrary Predicate<String> implementations from any class that we know of, but that is arguably not a good way).

• Another example is the way we treat JDK classes. Right now we mostly trust the JDK to work correctly. Note that this information is very implicit as of now. The use of contracts that describe behavior of JDK would make our "trust" in it documented to some extent and much more explicit.
• The same approach could work with some other libraries and frameworks. For example, we could use contracts to make some specifications on behavior of Spring framework. Hence, we would be able to work better with projects that use Spring.