should the DTO objetcs be mocked while testing controllers ?

Question

Its known that DTO doesnt have methods.

Since the controller uses the DTO objects , there is a dependency . should we set expectaions on the properties of DTO(mock DTO properties) while testing the controllers.?

thanks

Answer 1

Can you name at least one thing why not?

I can't.

P.s. i mean - why not to use properties. You got 2 controversial questions in your post.

Answer 2

I agree with Arnis L. You just pass your DTO to your controller during your tests (initialized with the values you need) and there's nothing to test in your DTO (unless you have some logic in your getter/setter but it's not really a good practice for DTO).

Answer 3

A DTO is so lightweight that the additional cost of stubbing it out just seems silly. Plus now you need an interface for your DTO or everything has to be marked as virtual...

Answer 4

Where a DTO is just holding values, there's no point in mocking it. Mock objects should be used to confirm how an object collaborates with its neighbour. If there's no real behaviour, if the DTO is not providing a service, then don't use a mock.

Answer 5

Are you thinking of the dto going into the action, or the one(s) coming out?

The one going in will be used directly against a repository, a service or some other collaborator. I would mock those instead and place my expectations there.

Your test code will also have full control on creating the ingoing dto.

If you like to use the outgoing dto, I would just grab that one from the ViewResult and verify it is the expected one. How you do that is up to you: You could mock the repository or talk to your persistence storage of choice.