[Feature Request] Introduce mock framework for unit testing about aptos-core

[sitalkedia]

@davidiw , @JoshLind - Thanks a lot for the feedback. Mock testing in my experience is more suitable for unit tests that are well contained in a class - it is not so well suited for integration testing like scenarios. Also, I don't want us to rewrite a bunch of already written tests just for the sake of bringing in the mock testing framework - that is definitely not the best use of our time. However, I definitely see a great value in using a mock testing framework going forward to make it easier for us to add unit tests. How about we can introduce the framework as a part of existing projects and transitioning any existing tests can be a lower priority for us?

[sitalkedia]

Yes, I plan to play around the library as a part of fine-grained storage project and see if we can standardize that library across our code base.

[davidiw]

Interesting proposal! I'd be curious if you could make this into more a first project. For example, the MockSharedMempool is complex code that actually wraps around other dependencies for testing them out, for example the CoreMempool. Is it also testing out other facilities? It isn't super clear to me just from looking at it. I would love to get rid of this hard to read "mock" code. I guess the question is ... if it is a unit test use mocks. if it is an integration test ... ?

[JoshLind]

@sitalkedia, yeah, this is something I brought up a while back (1+ years ago):

• The feeling I got at the time was that it's easier/quicker for most folks to roll their own mocks than rely on the libraries that existed back then. I know there's been a bunch of progress made in these libraries since, so perhaps they might better fit the purpose now.
• This definitely seems like something that might help improve the quality/readability of our code, but it's also worth calling out that most of the manual mocks that exist today provide just enough functionality to test what the author wanted. So, I think if we did start migrating things, we'd need an end goal that justifies the work. For example, if we're just porting for the sake of it, it's probably not worth it. But, if we can show that we're getting better test coverage, debuggability, etc., then it could be argued this is a good use of time.

[JoshLind]

How about we can introduce the framework as a part of existing projects and transitioning any existing tests can be a lower priority for us?

Sure, makes sense to me. 😄 It's worth noting that most folks will probably do what suites them best though, so you may need to convince someone to try it out (making these types of things mandatory before there is a clear standard tends to result in negative outcomes). Alternatively, you could be the one to experiment and see how it goes! Either way, it would be good to get some exposure to these libraries to see how well they support our codebase.

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove the stale label or comment - otherwise this will be closed in 15 days.