Question

I have a complex method I want to test,
It recieves user, UserUpdatedDetails(password, restore question and email) and password.

And it should check the following:

1. Make sure user updated all fields that he had to
2. Validate each field independently
3. Make sure password matches user password(Authenticate)
4. Update the required fields
5. If password / Question Answer has changed, re-encrypt special key for sensitive data (it’s a random long key that is used to encrypt sensitive data such as birthday, first name and stuff… the key is also saved by the encryption of password and question answer not the point right now).

The main method uses small methods, that uses other small methods.
The thing is they are all private methods, and there is no reason they should be otherwise (I am not going to use them anywhere else)

Testing this all thing is going to be a nightmare, And even if I would test each small method independently, It doesn’t give me a clear picture that the main method is doing what it has to be doing.

the Implementation looks somthing like this:

UpdateUserDetails(this User user,
                  UserDetails userDetails,
                  string Password,
                  out ErrorList<AuthErrors> errorList)
{
    UpdateActions actions;
    errorList = user.ValidateUserDetails(userDetails, out actions);
    if (errorList.IsSuccess() && actions != UpdateActions.None)
    {
         var status = Auth(user.UserId, password); // Easy to mock
         if (status.IsSuccess)
         {
             try
             {
                 var newUser = user.UpdateUserDetails(userDetails, actions);
                 commit;
                 return newUser;
             }
             catch
             {
                 rollback;
                 throw;
             }
         }
         else
             errorList.Add(AuthErrors.WrongPassword);
    }
    return null;
}
enum UpdateActions
{
    None = 0,
    Password = 1,
    Email = 2,
    Question = 4,
    All = Password & Email & Question
}

Edit:
By the way, It easy for me to Mock the Auth implementation, and also the DAL implemention(Updaing the user) all the other is the problem…

Just to give some point of view on the methods inside methods:

ValidateUserDetails(this User user, 
                    UserDetails userDetails,
                    out UpdateActions actions)
{
    actions = UpdateActions.None;
    ErrorList<AuthErrors> errorList = new ErrorList<AuthErrors>()
    if (userDetails.password != null || user.RequirePasswordUpdate)
    {
        errorList.AddRange(validatePassword(userDetails.password) // PublicMethod, already, which has tests.
        actions.Add(UpdateActions.Password) // ExtensionMethod
    }
    if (userDetails.email != null || user.RequireEmailUpdate)
    {
        errorList.AddRange(validateEmail(userDetails.Email) // PublicMethod, already, which has tests.
        actions.Add(UpdateActions.Email) // ExtensionMethod
    }
    if (userDetails.Question != null || userDetails.QuestionAnswer || user.RequireQuestionUpdate)
    {
        errorList.AddRange(validateQuestion(userDetails.Question, userDetails.QuestionAnswer) // PublicMethod, already, which has tests.
        actions.Add(UpdateActions.Question) // ExtensionMethod
    }
}
UpdateUserDetails(this User user, UserDetails userDetails, UpdateActions actions, string oldPassword)
{
    if (actions.Has(UpdateActions.UpdatePassword)
        user.UpdatePassword(userDetails.password)
    ...
    return DataAccess.UpdateUser(user); // Easy to Mock
}
UpdatePassword(this User user, string password, string oldPassword)
{
    user.Password = _IEncryptionManager.BcryptEncrypt(password); // easy to mock encryption methods
    user.SensKey = _IEncryptionManager.DesEncrypt(_IEncryptionManager.DesDecrypt(user.SensKey,
                                                          oldPassword),
                           password);
                                      
}

I’d appreciate the help,
Thanks regards,
Amir.

Answer 1

Don’t bother with testing private bits, UpdateUserDetails is what you’re interested in and this method should be tested primarly. Private parts will get tested as kind of collateral damage of public method tests. Best part is, you already know what you should test and you specified it yourself with the list you posted. However, it could be improved a bit:

Make sure user updated all fields that he had to

This essentially is input data checking and should be tested as such (what happens whenuser posted incomplete data? Exception, error message? This is what you want to test/verify – what happens when user didn’t update all fields and whether it happened indeed).

Validate each field independently

What happens when field is invalid? This is what should be tested (exception thrown, error message or so). Successful validation leads to successful update, and that will be tested in the final step.

Make sure password matches user password(Authenticate)

Usually authentication is heavy/complex process. Does it really need to be private as a part of user details update? Unless you have a very good reason to keep it this way, I’d say it’s a good candidate to extract to separate being and inject as dependency.

Update the required fields

This is the tested unit here and whether those fields got updated properly should be tested at this point.

If password / Question Answer has changed, re-encrypt special key for sensitive data (it’s a random long key that is used to encrypt sensitive data such as birthday, first name and stuff… the key is also saved by the encryption of password and question answer not the point right now).

Key generation should be done elsewhere, as in, it sounds like different responsibility than updating user details and maybe it’s worth to test it as such.