Today’s adventure is using CoPilot ChatGPT-5 to create a test and code based on a production database requirement.
I’m using RubberDuckVBA to do unit testing. My initial prompt to start the conversation was:
I am wanting to get help with creating tests for RubberDuckVBA for an Access program.
I am going to create a single file with a script which will upload all the files in a source directory in which all the Access objects are exported to for source control.
I will want you to only do one task at a time and not get ahead of my requests.
You will play the role of an expert TDD VBA Access developer.
You will ask me any questions to better understand your task as we go. Are you ready for the first task?
One quick thought is to review other developer’s prompts for more ideas here. For example, here are two links from NoLongerSet by Mike Wolfe:
A Simple Trick to Help ChatGPT Provide Correct Answers
And I’m considering adding common prompts if I end up with some to my keyboard expander program, Expanso.
Now, what happened?
Well, I gave it my full code base using a technique of putting the entire source directory I have into one text file (using a powershell script given to me by CoPilot of course).
Then I told it which form I wanted to focus on (frmShip which allows editing of individual shipments for a particular Job) and to update the ability of a navigation subreport I had created. Currently it was not updating when I added a new record.
CoPilot via ChatGPT-5 thought long and hard about each question and step it went through. It successfully gave me some code for the test module for RubberDuck which was good. It didn’t compile but that was to be expected in the TDD process.
Then it produced a new module for me with a public function stub which allowed the test to compile, but was still failing.
Next it attempted to make the test pass. CoPilot gave me more code and explanation for the function, but It forgot to add the End Function statement to the end of the function, so I added that myself.
It was supposed to pass successfully then, but timed out. This was because CoPilot had cleverly used Access DAO transactions to attempt to rollback the changes it was making, however doing a DCount on the table with the new record was causing it to time out which is a known behavior of DCount while using transactions.
So, that is about where I stopped for the moment. I’m now considering having it create an in-memory recordset or something. It has given an alternate testing method for adding the record and then deleting it, but I’m not sure I want to actually do that to my test database. It also sounds slow to me in terms of testing, and we want TDD tests to run fast!
Well, it was a fun exercise, but only was able to teach me one way to NOT test the database so far. Kind of like how Edison learned thousands of ways how NOT to make a lightbulb before arriving at a way that worked.