Given that the team inherited a legacy project where does not control the DB schema. Meaning, that anyone in our organisation can push changes to the big corporate DB shared with all other teams. Of course, changes are minimised in order to maintain backwards compatibility. However, I do not see the point to use partial (few tables) embedded or in-memory databases to test the persistence layer (DAOs).
What risk can actually be covered when our SQL scripts are not in synch with the PROD or SIT databases? At least until something is broken and we realise that our SQL scripts are not up to date.
I need another pair of eyes (+brain) to understand this kind of testing strategy.
What kind of testing would you apply to the persistence layer in this tricky situation?
Many thanks in advance,
Aucun commentaire:
Enregistrer un commentaire