I'm currently designing a COM DLL in
.NET for use in MS Access by a few other developers. The Access application is hooked up to a SQL-Server & is supposed to just act as a front-end, but currently it pretty much does everything. Ideally we would like to separate the business logic into a separate entity to Access can be restricted to acting as just the front-end.
If the developers are working on a method that is supposed to perform some basic CRUD operations on the data they switch their
ODBC Data Source over to test (just a localhost server) whilst the production application is hooked up to a live connection.
What I've done in my DLL so far
So in designing / testing my DLL I have worked exlusively in my own personal test server (localhost). So one of the requirements has been for the DLL to be able to connect to the same server as the local
ODBC Data Source that the user has. I've managed to configure that fairly simply.
The way I do this is by Access writing a connection string to a local file the DLL can access whenever a class is initialised in Access.
I've been advised to add some unit testing for all of my CRUD operations against the database that are being performed in the DLL. However, these unit tests fail when being completed in Azure DevOps during my build event as the localhost isn't available to use.
I was thinking about adding a 3rd database to the mix, a code first
SQLite database that will be created & torn down during the unit testing process.
My original thought was to create this using a series of
SQL statements to be executed but it was getting very messy very quickly so I've put that branch on hold for now.
Am I overthinking this? I've never designed anything like this & I'd like to try & work to some strong guidelines from an early point in time of the development on this project to avoid to much re-work later on.
Would this approach be considered a good practice? If not, what would you suggest / what should I be searching for? My knowledge on this is quite limited & I feel that I'm probably searching for the wrong thing.