My system consists of 4 seperate layers.

  • API layer
  • Application layer
  • Infrastructure layer
  • Core layer

System is not Domain Driven. It contains no entities with domain logic. All models are anemic. System uses third party SDKs to do CRUD actions on external resources that are not owned or managed by me.

Commands and queries follow the same steps: API -> Application -> Infrastrcture.

1) API layer - consumer HTTP POST request, creates command and using mediator passes it to Application layer,

public async Task<IActionResult> Create([FromBody] CreateJobModel model)
    var command = model.CreateJobCommand();
    var commandResult = await this._meidator.Send(command);
    return Ok(commandResult)

2) Application layer - consumes and processes command. IJobsService is injected using DI.

private readonly IJobService _jobService;

public async Task<JobResponse> Handle(CreateJobCommand command)
    var result = await this._jobService.CreateJobAsync(command.Id, command.Payload);
    return result;

3) Infrastructure layer - contains concrete implementation for IJobService. Note here that JobClient is Microsoft SDK with it's own Exceptions. e.g. InvalidPayloadException.

internal class JobService : IJobService 
    private readonly JobClient _jobClient;

    public JobService(string connectionString)
        this._jobClient = JobClient.CreateFromConnectionString(connectionString);

    public async Task<JobResponse> CreateJobAsync(sting id, string jobPayload)
        JobResponse response = await this._jobClient.CreateOrUpdateJob(id, jobPayload);
        return response;

Core layer - JobService contract/blueprint

public interface IJobService
    Task<JobResponse> CreateJobAsync(sting id, string jobPayload);

The question

Is there any value in writing Unit tests for any of this? If yes, then where would I start?

I could be wrong here, but I don't see the value of mocking JobClient, plus all the unit and intergration tests for this particular SDK are already written by Microsoft and available on GitHub - I don't think there's point in creating tests to see if correct exceptions are thrown when such tests already exist on SDK creator's GitHub repo.

1 Answer 1


Unit testing is about testing the units you write meet the expectations of them. So in general, you really only want to test your code--not the whole infrastructure for the code. At least that's the general idea.

Stuff you don't want to test:

  • Actually forming HTTP requests to call your controller code, you can simply call the method in the controller directly.
  • Code that is outside the boundaries that you wrote (i.e. code that Microsoft or some other 3rd party wrote)
  • Compiler generated code (auto-properties, or UI template code)
  • Things that are too simple to test. Think one line of code with no side-effects.

Now, the concept of mocking is simply one mechanism to isolate the code you wrote from the rest of everything else. The intent behind mocking JobClient or any other class is not to reproduce all the functionality, but to make sure your code is interacting with it in an expected way.

With the idea that unit tests are intended to test just the part you wrote, you'll want them at all levels of the application. That means you'd have written them at the application layer and the API layer. Infrastructure layer should only have tests if you wrote the code. I.e. you are only testing the parts you wrote. I'm assuming what you call the "core" layer are 3rd party and core libraries. That's not code you wrote so don't test their stuff.

Now, there are areas where code is to complex to test independently. The reasons can range from the code you inherited wasn't designed for testability to requiring complicated methods of invoking actions (like with UI testing). For those you may rely on other forms of testing to ensure they are correct. Integration testing tests everything as it is connected together, and should be limited to enforcing business specifications. Manual testing should be included in some capacity when you have complex user interfaces.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.