One common pitfall that keeps poping up in my life is doing tests always with superusers/admins/roots, and then having problems with normal accounts.
This is utterly wrong, because admins are the smallest segment of your users, and thus should be the last ones to take into account for tests.
A typical scenario is disallowing doing stuff, accessing content, etc.:
In a screen of a "delete content" control you might want to optimize the code by not doing anything if you are not supposed to view it; The typical "if (user.canDelete(Item) { //renderdelete button } else { //do nothing }".
But what happens if you forget to start the rendering code/markup with a "if (user.canDelete(Item) { ..." ?
Either everybody will see the delete button, or something will break further in (hopefully, as allowing everyone to delete content is catastrophic).
It is very important to either have a mechanism/architecture to add this checks automatically, or to double and triple check they are present, and in the correct spot.
Another example of bad practices:
Imagine you are building an item deletion feature: A user can delete something if he was the creator, or if he is an admin.
First approach could be to implement a user.CanDelete(item) that checks user.IsOwner(item) || user.IsAdmin(item) and this will work until we add another category of user (for example, moderator). Now we need a user.IsModerator(content) because is not an admin.
I've seen people do similar approaches as:
public bool CanDelete(object Item)
{
bool canDelete = true;
if (!this.IsOwner(Item) && !this.IsAdmin(Item))
{
canDelete = false;
}
return canDelete;
}
A basic refactor to just one line would avoid the false positive problem, but wouldn't fix the false negative that might arise. Plus it places all users in two flags: owners/no-owners and admins/no-admins. Adding a moderator would need a first rewrite. Adding special users would need more. Adding visitors (maybe read-only access to every part of the site/application) might need even more checks.
The solution is quite easy: Build a role +permissions system, doing more "meta-data" coding (user.IsInRole(xxx), role.CanDelete(xxx), etcetera). It is way more better to have a role-based security, with HasPermissions(action) methods, or a permissions manager and then send both the action and subject to it.
Any solution that tries to simplify the logic as much as possible, encapsulating the logic and adding reusability in the process; providing as less entry points to security checks as possible, so that you know you have to only check and modify security logic in one or two places.
It is critical to test this delicate conditionals, so if they are either by convention in a method or all in a separate class make sure to see the logic and try to break it in the tests that fully cover all cases.
Also, by testing with superusers we might get side-effects:
Just think what is better: To have your website broken for the two administrators, or for thousands of users and visitors? First make sure your site works for the common scenario and majority of users, then go with the non-standard cases or the rest of the roles.