Refactor and reorganize integration tests in hedera-mirror-web3 module

[IvanKavaldzhiev]

Problem

Currently all integrations tests in hedera-mirorr-web3 rely on a DB test setup, which is processed in ContractCallTestSetup, which creates a strong dependency between all test data. As a result if we change the ID of a single entity, for example, we might break an existing set of tests or see unexpected results. In addition maintenance and adding new tests with new test data would become harder and harder in the future.

Solution

Remove ContractCallTestSetup as a central database setup and refactor all integration tests to include their own test data and be self-sufficient without relying on an external setup. Each test should create their own entities and needed data, that would be discarded after the test execution.

Some extraction of ContractCallTestSetup logic into the separate integration tests, might be an option, but probably the best approach would be adding new DB test data for each separate test from scratch and reuse as much shared common methods for a data setup, within a given integration test suite, as possible, without the need of specific entities for each test (e.g. tokens, accounts, contracts). Avoid extracting common entities and methods in a parent class, as eventually we would construct the same problem of a common big and complex class with DB setup.

Alternatives

No response

[steven-sheehy]

In addition to separation of test data across tests, I would like to also see separation of test data between tests within a class. This should be done by generating test input instead of relying upon hard-coded, static data. With this approach, there should be zero static constants at the top shared between different tests even within a test class.

The general principle in mirror node is to use the DomainBuilder to generate as much as possible of the data, only overriding specific fields that are necessary for the test. That is, IDs should not be overridden and left random except if you need to link object B to object A by setting b.setA(a.getId()), which still uses dynamic data. Then the test output should be compared against the dynamically generated input for correctness.