If a plugin uses a type: group it must have the group created (e.g., when the database is migrated, or perhaps after_initialize) in order to pass specs (else, the spec fails because settings include a group that does not exist). My solution was to make these type: group settings instead be type: text. That way the settings don’t fail because the group doesn’t exist, I can create the groups in my specs with let!, and the groups are gone when the Group specs run.
If there’s a better way, I’d love to hear it. Arguably, for this case, I’ll likely never need to change which group is used for each of these purposes, so they could just be hard-coded in the plugin and not be settings at all.
Ramblings on how I figured out the above
I’ve got a plugin that needs a set of groups. When a user is added to the group, an action is taken in my model. It works fine in production and development databases. Yippee. 
The problem is that for specs, either the groups get created (I’ve tried doing that in a function that gets called in after_initialize and with fixtures that get run during migration), which breaks the core Group specs (that e.g., expect there to be a certain number of pre-existing groups), or the groups don’t get created, which breaks my specs.
I overrode refresh_automatic_groups in the Group model and have it delete my groups. That fixed all but one test, as my group names include a couple that include some of those strings and that spec doesn’t call refresh_automatic_groups.
https://github.com/discourse/discourse/blob/master/spec/models/group_spec.rb#L907-L920
So my solution was to use only names that don’t break that test.
EDIT (Again): but now I’ve still got errors in destroy_task_spec.rb and the group_controller.
Is there some simple trick I’m missing or do I need to just make this plugin not create groups automatically?