Debug workflow

[PioPio2]

Hello,

Mine is more a question than an issue and it is regarding the debug workflow.

I have an Access application and periodically I have to amend parts of it. What I want to achieve is to export the modules and classes from the production application, then import them in a separate Access application where I run all my tests. Once I am happy I do the reverse and export these amended classes/modules from the test application and import them in the production application. Is there a way to do that or a simpler way?

Many thanks
Alberto

[hecon5]

Option 1: (Simplest)

You can simply export, copy the relevant modules, do a build for your separate application, test, and then export that once you're satisfied, paste it back into the main application and do a build.
Difficulty: if you can CTRL+C, CTRL+V, you can do this.
Tedium: Medium. Copying and pasting can be annoying.

Option2: (Most Consistent and potentially robust)

Use RubberDuckVBA and add testing directly to your primary database. See modUnitTesting.bas for some tests, and the \testing\ directory for the example database (which runs the tests). In there is a post-build routine called RunAfterBuild (clever), which runs the unit tests after building.
Difficulty: Medium, you have to build the unit test module to validate functions.
Tedium: High for initial build, low after (it's self-sustaining).
Upside: Your application contains all the functions and references of the full build, and you won't end up with ghosts due to unexpected interactions.
Downside (if you can call it that): Additional bugs and features need to have additional unit testing added.

Option 3: (Blended upsides)

Workflow branching; I do a bit of this in conjunction with the Option 2. I simply build on a separate branch from the repo, do any testing, export any fixes and merge them back in. All the simplicity of Option 1 without Copy/Paste, and all the upsides of Option 2 because I can do additional bug / troubleshooting on the full build.

I'm sure others have other ideas and some of them will be a lot better, but that's my 34.5 cents.

[joyfullservice]

I would second what @hecon5 describes above. If you are able to incorporate the testing framework into the production project, it will give you a consistent codebase for development as you go forward. I personally prefer the workflow branching approach, where you can simply switch to a different branch in git for testing and development, then merge those changes into the main branch when they are production ready.

The great thing about the way this add-in works is that you can build a fully operational database from a set of source files. This allows you to update the source files themselves (for example, through a git commit that pushes your changes up to the main branch) and you can then rebuild your database from source to see those changes reflected in the production application.

It is a bit of a mentality shift initially, but the benefits are huge from a development and maintenance standpoint. You might enjoy this video where I demonstrate how to do this using GitHub Desktop and a sample database.

[PioPio2]

Thank you both for your help, first of all

I watched the video and read all your comments. The main reason why I was asking the question in the first place is because I didn't want to include the tests in the production version of the application but at the same time, I wanted an easy way to perform the tests and merge them into the production version once happy.

What I have done is

• I exported all the components from the production application
• I made a copy of the production application and called it "TEST"
• This is where I will perform all my tests on classes/modules/queries etc
• Once happy with the tests I can export the tested components from TEST and then build the production application. This should update the production application without the tests
• Committing periodically using branches should give me the chance to roll back if needed.

Is it a good idea? Can you see any drawbacks?

Many thanks
Alberto

[joyfullservice]

Hi Alberto,

Do you mind if I ask why you don't want the testing code in the production application? Two possible reasons that I could think of would be not wanting to clutter up the project with additional code, or because the testing code requires additional dependencies that you don't want to be added to the production application. Also, which framework (if any) are you using for testing?

Personally, I usually try to go for the least complicated approach when I can. The more I can automate or reduce the steps involved, the more efficient I am in the development cycle. Having all the code in the same place makes it easier to maintain.

Perhaps if you could share a little more background about your testing approach, we might be better able to offer suggestions. For example, are you sharing the same tested modules across different projects? How do you run the tests? Do you use an add-in for that, or an internal form, or just run a command from the immediate window? Some idea of the scope of the project would be helpful as well.

What you describe should work, it just seems like a lot of manual steps involved. Understanding your process a little better may help us provide some better recommendations. 😄

[PioPio2]

Hi Adam,

The decision to keep the testing out of the production application is not to clutter up the project, as you say. The final user will never use the testing code, as the developer does all the testing before release.

For testing, I use VBA Rubberduck (I like it because of the level of integration of the test results) but I noticed the application freezes often. I made a test on a smaller project and it is much better; finally, I learned that Rubberduck parses the source, which may cause the freeze (the bigger the source the longer it takes to parse it). That is the second reason I have chosen a different approach.

My application is a financial one, nothing rocket science, just forms, queries, interaction with Excel, Word and Outlook and some integration with APIs. What I test is queries and the business logic I put in classes.

Many thanks
Alberto

[joyfullservice]

Thanks! That helps to understanding more of where you are coming from. RubberDuck is an awesome tool, but as you have found, it unfortunately doesn't scale well to a larger code base. I know that the developer has been working on a major rework to address this, but it is a rather challenging problem to solve, to say the least, given the particulars of the VBA IDE. AccUnit runs great on large databases, but doesn't have all the bells and whistles of RubberDuck.

One idea you could consider would be tapping into this add-in's AfterExport hook in the main project, and create your own VBA function that copies the relevant testing files over to another folder where your testing project lives. This way, when you export source code from the main project, it will automatically drop copies of the queries and classes into your test project. Then, you can open your Test project, merge from source, and run your tests.

It sounds to me like you are taking a pretty reasonable approach, all factors considered.

[PioPio2]

One idea you could consider would be tapping into this add-in's AfterExport hook in the main project, and create your own VBA function that copies the relevant testing files over to another folder where your testing project lives.

I was not aware of this option, it sounds very suitable for my case. Thank you!