Organzing Libplanet.Explorer.Tests

[longfin]

Related comment: #2186 (comment)

Originally, the function expected that all GraphQL types would have a no-arguments constructor. But the assumption was broken so this pull request's CI was also broken.
To resolve it, it should rewrite GraphQLTestUtils.ExecuteQueryAsync with ServiceProvider and ServiceCollection 🤔

@moreal Thanks for detailed but on second thought, lookup with ServiceCollection or ServiceCollection seems a little bit weird if we want to write a unit test for just BlockType, because DI's main concept (injecting dpes on constructor) aims easy testing in general... 😕

AFIK, we want to change the injecting method for static dependencies from UserContext to general.NET DI scheme. (like #1936). as @moreal pointed, it will break assumtion on that types. so it seems that we have to introduce DI convention such as ServiceCollection.

but on the other hands, DI tends to help unittest since it reveals hidden dependencies on some object to unified way.

DI helps testing

Let's assume that some class T relying on IStore and it retrives an implementation of IStore on other external registry.

class T
{
    private readonly IStore _store;

    public T()
    {
        _store = IStoreRegistry.Lookup();
    }
}

In generall, T is considered that very tricky class to testing, because if we want to change implmentation to tests, we need to check IStoreRegistry and learn how can we add a new implementation for testing.

Actually, DI framework also does very similar work in generalized way. if T is under DI, it seems like that

class T
{
    private readonly IStore _store;

    public T(IStore store)
    {
        _store = store;
    }
}

In that case, we don't need to lookup since it's done on DI side. but more important thing is, we can write the test like as below

var t = new T(new MemoryStore);
Assert.True(T.SomeMethod());

DI is distrubing tests now

Nevertheless, in many case DI can disturb existing codes. For example, BlockTypeTest is using actual query literal and the environment to execute query. in this situation, we need to any method (Whether it is IStoreRegistry or ServiceProvider) to organzing many related dependencies.

I think that there are two possible approaches.

Seperating type testing and query testing for GQL types

When I first saw the BlockType tests, I was only concerned about how to inject dependencies well. however, I soon realized that this test was a test for a type called BlockType, and I was a bit skeptical as to whether a query literal was absolutely necessary to do this.
I don't know best practices about unittesting for ObjectGraphType<T>. but I believe that it's worth that researching about field testing without full schema.

Introducing service provider for test project

Even if we narrow down the testing scope of types, it's still worthwhile testing through queries. for that case, we still need to organize DI.

In this case, I think it is important to use a method that is as general as possible and can be easily predicted by project contributors. Personally, I think the ideal is to configure the environment in the same way as injecting Libplanet.Explorer. Of course, we should change some implementation like IStore for testing. 😅