Testing Access forms and controls is really integration testing. I wouldn't run those tests against your live front end or live data.

A good approach is to keep as much logic as possible out of the form module. Put the "change state" rules in regular procedures or class modules, test those with Rubberduck, and let the form code be a thin layer that calls them.

For the pieces that truly require a form, open the form hidden in a separate test copy of the database, set control values, call the procedure you want to test, and then check the resulting control properties or record values. For example:

DoCmd.OpenForm "CustomerF", WindowMode:=acHidden
Forms!CustomerF.Status = "Active"
Forms!CustomerF.UpdateStatus
Debug.Assert Forms!CustomerF.StatusLabel.Caption = "Active"
DoCmd.Close acForm, "CustomerF", acSaveNo

Changing a control's properties at runtime generally doesn't change the form's design. The important part is closing with acSaveNo and making sure your code isn't explicitly saving the form design. Bound controls are different, of course - changing their values can write to the underlying table, so your test database should use disposable test data.

I would make a separate test front end linked to a separate back-end copy. Then your tests are free to open forms, add records, change records, and delete records without risking production data. Think of the UI tests as a smaller set of smoke tests, while most of your detailed testing stays in ordinary VBA modules where Rubberduck shines.