mspec & rhino mocks expected exception testing

I'm fairly new to unit testing and can't get around how to test (or if I even should) this case properly.

I have a controller method (pseudo code):

public ActionResult Register(formModel model)
{

    if (ModelState.isValid) {

        try {

            _userService.CreateUser(a bunch of parameters here);
            return RedirectToAction(some other action);
        }
        catch (Exception e)
        {

            ModelState.AddModelError("",e.Message);

      开发者_JAVA技巧  }

    }

    return View();
}

I have a bunch of separate tests against "_userService". The "CreateUser" method just creates a new user and returns nothing OR throws an exception if there was an error (ex. the user exists) that I bubble up to the controller surround in a try catch and add the exception to the ModelState.

From what I understand I should mock the service and assert that it was called correctly (i use the assertwascalled syntax) since it returns nothing and I just want to know that my controller calls it.

What I'm not sure is how to test that when the userservice throws an error it should not redirect and should add that exception to the modelstate. With rhino mocks you can stub a mock but the book art of unit testing advises against that.

Right now in my test I manually add a model error (not caring if it's from user service) and test that the controller returns the same view if there are errors. Is this the correct way of going about this? Or should I maybe create a separate test where I stub the _userService to throw an error and check it gets added to modelstate? Or should I not even test that case? I feel like I may be just over analyzing the whole thing and testing using the modelstate would be enough to satisfy this...

Your mock represents a collaborating class. I wouldn't get too hung up on the difference between mocks and stubs; it's still a collaborating class.

You can think of your unit tests as describing how to use your class, and how the class then interacts with its collaborators. You have two examples:

Given a controller
When I register the model
Then the class should ask the user service to create a user.

And:

Given a controller
Given the user service is broken
When I register the model
Then the class should attach the error to the model state.

It's that second Given that tells you you're stubbing rather than mocking. You're setting the user service up as though it's broken. The context in which the class acts is different, so you need to stub, and you should indeed throw an exception.

If you put these lines as comments inside your test, it'll make sense. If it makes sense, ignore the book.

BTW, this is unit-level BDD. You can use "Given, When, Then" at a unit level just as at a scenario level, and it might help you think about the logic of your tests. Just don't use BDD scenario tools for this.