As noted by the question's title, what is the best way to preform unit testing on an application that behaves differently depending upon what user is currently logged in?
Also, for applications that maintain information on the internal state, what is the best way to preform the testing and to manage all of the tests?
Create separate tests for the different types of user and simulates them logging (or being logged) in. This way you can test for each type of user what should be the behavior, based the users permission, for example.
If the internal state of the app also plays a role, you're pretty much stuck with creating tests for every (reasonable) scenario.
If what defines the behavior is solely the logged in user type then its easy just write a test for each user type [you end up with n tests; n is the number of user types].
If its a combination between some internal system state and the user type you write a test for each state for each user type [you end up with n*m test; n is the number of user types, m is the number of internal system states].
If by user you mean system user e.g. windows login - then for unit testing it would best to decouple you're code from this dependency.
By this I mean let your code have an internal concept of user that is easy to set in unit tests. Then the majority of your code would only know about this internal concept and can be tested without worrying about the real login.
Then the harder layer to test (the layer that maps the system user and all things you derive from that e.g. folder locations, permissions etc. - to your internal login) is minimised. Some type of acceptance testing that can deal with high level logins can then be used to test this layer.
I assume that there is some provider that says "this user can do this action" or "for this user, perform this action".
If that is the case, you just create a stub for that provider and let it return different things for the situations that you want to test.
If it's not the case, I'd create such a provider.
The same goes for state: Store the state in a state-keeping class and ask it what state you're in. In a test environment, create a stub for it.
Of course, you can then also unit test the state-keeping class.