Skip to content

Avoid dynamic mocks for common "data" types #2593

Open
@IlyaMuravjov

Description

@IlyaMuravjov

Description

Right now in Spring unit tests fuzzer when initially creating mocks doesn't mock any methods. Only when it gets feedback from the concrete execution about invoked methods it does the actual mocking of these method. Although, even after that it may still choose not to mock them (e.g. if they are too deep, by default fuzzer recursion depth limit is set to 4).

To complete concrete execution when invoked method of the mock is not mocked, we create answers at runtime. For most types we use mocks as default answers, to achieve maximum coverage and make discovery of methods to mock faster.

However, that sometimes causes us to mock types that should not be normally mocked (e.g. List and Optional).

That is bad because mocks of such types can have a nonsensical behavior (e.g. we can have List that returns false when isEmpty() is called on it, while returning 0 when size() is called on it), also, sometimes mocks are unable to cover certain instructions, for example, if we mock Optional we won't be able to cover lambda that is passed to orElseGet method).

Metadata

Metadata

Assignees

No one assigned

    Labels

    comp-instrumented-processIssue is related to Instrumented processcomp-springIssue is related to Spring projects supportctg-enhancementNew feature, improvement or change request

    Type

    No type

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions