Test Database vs Mocking Database

[b00f]

Description

To test commands, we have mocked the command dependencies. This way, we can easily test the commands. However, the Database module is a large module and changes constantly.

We have defined an interface for the database and mocked it for now. Another approach is to create a temporary (perhaps in-memory) database for testing. This way, we should ensure that the database will not be stored on the system and will be deleted after testing.

Before taking any action, let’s discuss here and share ideas.

[b00f]

Since the database evolves over time, defining an interface for it has some disadvantages:

1. Increasing Database Methods:
   The database methods are constantly growing. Currently, the Database interface consists of six sub-interfaces, and this number will increase with future developments.

2. Lack of Unit Tests for the Database:
   Writing unit tests for the database is not a common practice among the development team. At the moment, there are zero unit tests for the database.

Advantages of Defining an Interface:
The main advantage of defining an interface is that it allows us to mock complex code and write simpler unit tests. However, mocking the database may not be effective since each test might involve calling different methods, making the tests more cumbersome.

Suggestion:
I recommend removing the interface from the database and ensuring we can use an in-memory database like sqlite:memory. A database is a place to store and retrieve data, and this approach offers the following benefits:

1. Database functionalities will be tested implicitly.
2. Mocking functions for unit tests will be significantly reduced.