I should test even the failure cases?

Yes :-) Imagine you only test a successful login - in that case the following code would pass :

function login($username, $password)
{
  return true;
}

But that's obviously not what you want to happen in your application :-)

@coder81 Yes, you should test cases you expect to fail as well as those you expect to pass, i.e. make sure disabled users can’t log in, or in your case that a moderator can’t delete a user. If these cases return true, then you have a bug, so it’s beneficial test these cases.

@ohffs Do you think I should test even every required field of a user? Suppose my user have 10 required fields, I need to do 10 tests, everyone with all fields filled except the one that I test.

'Need' is always a judgement call - it's really up to you. I have some apps with almost 200 fields per form and there's no way I'm writing tests for them all (especially as they change fairly frequently). But I do test key ones that impact on other important features in the app (like dates being valid ranges, or particular radio/select boxes being enforced).

It's had to test every case though - there will be some bug somewhere. For instance I often use an LDAP server for authentication and I do a basic pass/fail test with a valid username & password, an invalid username, a valid username but invalid password and an empty password. But as I discovered today - the LDAP server is lower-casing all passwords so "MYPASSWORD" and "mypassword" will both let you log in. I never spotted it before as I would use a bogus password like "not-mypassword" to test the failure case. Just happened that today I just uppercased the valid one in a test and 'failed to fail' :-)

So generally cover the cases which are important for you and try and think of a few 'what could a user do that would mess this up' failing tests too :-)