Using Inversion of Control allows the difficult to spin up components such as the database to be abstracted away in a test script.
I would also be cautious about using Entity Framework… it works well for brief, few-record edits, but it starts to fall down when you need to edit across joins or large datasets.
Additionally, EF’s abstraction detracts from the advantage of RDBMS-native procedures which run much faster and are simpler to code.
I’ve had plenty of ORM related issues in my career. You can never escape SQL no matter how magical your ORM is. Using in-memory sounds like a fine idea for running tests, but I’d like to be able to match production on my local environment easily. Maybe the build should have a build local and build dev options
Do we need to wait for ArtOfCode / a team lead to make a decision on this? I don’t want to make a pull request if we’re undecided. Things can always be changed later
That’s… a good question that we haven’t actually got a policy for, but we’re sorting that out. But hey, if you want approval, you can have mine - a build script is a good idea.