Fix order-dependent DesignManagement::SaveDesignsService spec
This spec uses `build_stubbed`, which uses IDs starting at 1000 and incrementing on their own internal counter. It appears that we had a combination of specs where this ID matched an actual database ID of a user with access (probably `developer` in this spec file), which is unlikely but not impossible. By using `non_existing_record_id` as the ID for this stubbed record, we ensure that can't happen.
Showing
Please register or sign in to comment