Mocking Mappers?

In the past I never would mock a mapper, mostly because this typically are static methods and mocking static methods either wasn't easily possible or (as mentioned in the previous blog posts) result in less clean test code. With the usage of BDOs there is a lot more mapping going on, and I have been reconsidering whether or not mocking mappers is a good idea.

The main reason I am now considering to start mocking my static mappers is because without doing so, my code actually becomes harder to test. Well, it becomes harder to verify something in my tests. Imagine the following scenario: you have a controller that takes a DTO, maps it to a BDO and passes that object on to your service. The service would be mocked, but the mapper to convert the DTO to the BDO not. In your test you must verify the object being passed to the service is the correct object. Since you have no control over the creation of the object, you can not just verify it is the same object. Instead you have to verify the value of all the fields.

For the controller case mentioned above, this isn't that different. As the JSON request would get mapped to the DTO automatically, so if you would pass on the DTO to the service you would still need to verify all the fields of the DTO object. As I however pointed out in some previous blog posts, I am trying to achieve more independent services, and thus more mappings. For instance, my storage service would have to do the exact same thing, mapping a BDO to a DAO and pass it on the the repository. Here again, you would have to check each field by itself. In both cases, it would be much easier if you can just verify that the mapper is called using the correct object and return some object yourself. You can than verify that that object is passed on to the next service.

Another big concern I have, is that all my tests now become more fragile, in the sense that if there is a bug in the Mapper, all the services that use that mapper will have failing tests as well, even though that service is working correctly. Since I am a purist regarding unit tests, this is far from ideal. Hence the idea of mocking my mappers.

I have not yet put this idea in practice, or my idea of how a mapper should look like is already changing. If you have DTOs, BDOs and DAOs all nicely separated, and the same is true for your services in the form of front-end services (controllers), business services (actual service) and storage service (storage service and repository) there doesn't seem to be that much overlap. The front-end services only ever see DTOs and BDOs, while the storage service only sees DAOs and BDOs and the business service only knows of the BDOs. Why would you not split the mappers as well? This would split the mappers into a front-end and storage mapper.

This may cause the mappers to becomes very small, so small they may even become obsolete. Why not just have the mapping logic in the front-end and storage service respectively? In the end, mappers are just some boilerplate class and if we can get rid of them, that is only a plus in my opinion. But why even have that logic in the service to begin with? Why not have the logic in the object itself? That is, the DTO and DAO can be converted to and from their BDO form.

The latter is the approach I am currently trying out. I am not sure if that would make my testing approach much easier though, should I then pass mock objects to my methods such that I can verify the method being called and have control over the object creation? I will have to experiment with that, but at least I feel my actual code will benefit from this.

So what started out as a feeling that I would have to mock my static mappers resulted in the complete removal of the mappers. Whether or not this makes testing easier is to be determined, and I will update you about this in the future.