Adapter - Persistence - Redis - Consolidate mapper tests

[valentinajemuovic]

This ticket is about a theme that took me years to realize.

Several years ago, I used to do Mapper tests, well that was how many people did it too. The challenge here is that the mapper is an implementation detail, so then we're coupling our test to implementation. See meetup by @peterschuler https://www.youtube.com/watch?v=D5YSQkNFu_E

In general, when testing adapters, we want to test just the driver port interface, not the adapter implementation details. More specifically we're interested thus in just BankAccountStorage interface and don't care about how we implement it (don't care about how mapping is done, or whether or not you even have a mapper).

The file RedisBankAccountStorageTest extends BankAccountStorageTest. When opening BankAccountStorageTest we can see any test methods, for example the test method should_return_added_bank_account() creates some account, adds it to storage, and retrives it, verifies that it is equivalent to the added bank account. This serves as proof that any mapping (which is an implementation detail) works correctly - when we can retrieve back the same object that we had persisted. Thus, BankAccountStorageTest is already transitively testing mapping correctness; we do not need any additional mapping test.

Thus:

• The file BankAccountMapperTest is redundant for two reasons: RedisBankAccountStorageTest which extends from BankAccountStorageTest is already testing adding and retrieving, those tests can only pass if mapping works correctly (so if you introduce a regression bug in the mapper, that test should register it -and fail).... Hence action: deleting the file BankAccountMapperTest
• You can review BankAccountStorageTest and if you see that there was anything in BankAccountMapperTest but not covered in BankAccountStorageTest, then you can improve BankAccountStorageTest if needed.

Thus from the purpose of the adapter, just test file BankAccountStorageTest is enough... (targeting BankAccountStorage) because that's the only "public" part of the module, everything else is internal to the module.

[JoaoCipriano]

Thank you for this excellent explanation @valentinacupac!