I did this recently and feel like I only updated a few tests (maybe five or six?). So long as email remains a key identifier of a Accounts.User, you shouldn’t need to go adding username everywhere you see email and password (or even just email) in the tests. So long as you have some tests asserting that a username is required, present, and unique, that should be enough coverage around it. Apart from that, you just need to update the fixture to ensure you don’t have to worry about adding a username for tests that aren’t concerned with it.

Of course, if you are going to allow users to login with their username instead of their password, that’s a different story. It still shouldn’t be that many test changes. You’d need to update any place that fetches by username/password, but once you have a loaded user, the rest of the functions that use email can stay the same.

Another route I’ve taken in a multi-tenant app is to leave the Accounts context completely alone. Once a user logs in with their email and password, they become an OrgMember in an Orgs context (for example) and choose a username post-registration. OrgMember can either be its own table or it could point to the users table (there are pros and cons to both ways). In either scenario, the only thing OrgMember schema needs to know from User is email. This way, way you have really clean separation between authorization and the rest of your app and you don’t have to futz about with generated code.