Unit Testing - Defining the scope of the test - unit-testing

Question

I am trying to figure out the right way to break up my unit tests.
Given the following two classes, one is a CategoryService and the other is a CategoryValidator using FluentValidation, how would you write these tests?
I have tried writing a test for the service and one for the validator, but how do I test that the validation works in the service? Or is that out of scope of the test for the service and should be covered in the validator test?
In the AddCategory method, I am testing that the category name does not already exist in the validator. How do I test that in a unit test? Or is that an integration test?
Category Service
public class CategoryService : ValidatingServiceBase, ICategoryService
{
private readonly IUnitOfWork unitOfWork;
private readonly IRepository<Category> categoryRepository;
private readonly IRepository<SubCategory> subCategoryRepository;
private readonly IValidationService validationService;
public CategoryService(
IUnitOfWork unitOfWork,
IRepository<Category> categoryRepository,
IRepository<SubCategory> subCategoryRepository,
IValidationService validationService)
: base(validationService)
{
this.unitOfWork = unitOfWork;
this.categoryRepository = categoryRepository;
this.subCategoryRepository = subCategoryRepository;
this.validationService = validationService;
}
public bool AddCategory(Category category)
{
var validationResult = validationService.Validate(category);
if (!validationResult.IsValid)
return false;
categoryRepository.Add(category);
return true;
}
}
Category Validator
public class CategoryValidator : AbstractValidator<Category>
{
public CategoryValidator(ICategoryService service)
{
RuleFor(x => x.Name)
.NotEmpty()
.Must((category, name) =>
{
return service.GetCategories().SingleOrDefault(x => x.Name == name) == null;
});
}
}

Answer 1

Some people might find this heresy but I prefer to have things under test even if the test is bordering on that of a integration rather than unit. You just need to make sure your checks are comprehensive.
Don't worry about how the tests interact between classes, if you are starting out in unit testing (as I suspect you are) then it is better to write tests and the final D of TDD will come naturally.

Answer 2

I think you should test validator and service separately. Say for service test you can mock validator to return specific results without polluting your test logic with too many details (pseudo-code)
test Should_Add_Category_Only_If_It_Is_Valid() {
//given
Category category = GivenACategory();
GivenValidatorAcceptsCategory(category);
//when
Bool result = service.AddCategory(category);
//then
AssertTrue(result);
VerifyServiceHasCategory(category);
}
test Should_Reject_Invalid_Category() {
//given
Category category = GivenACategory();
GivenValidatorRejectsCategory(category);
//when
Bool result = service.AddCategory(category);
//then
AssertFalse(result);
VerifyServiceDoesNotHaveCategory(category);
}

Answer 3

What you're addressing is beyond the definition of unit tests. Unit tests test units ;) So write unit test for the service with stubbed validator, and for the validator with stubbed service. Then write some integration tests and these will validate whether your components interact properly.
However, it's always a matter of how you define a component (a unit) in your system. If you expose the functionality of the service and the validator together as a package, then write unit tests for them together, treating them as one unit, and don't bother thinking how they work inside - expect just correct results of particular "API" (in the meaning - exposed interface) calls.
You can combine these two approaches, and test service and the validator as one unit, but being aware of it's internals using the White-box testing approach. However, this is discouraged for large components, and I think it's obvious why.
Finally - do all these names matter? They are just names, can't I have just tests? IMHO, it is important to denote the boundary between unit tests - which should test absolutely everything (meaning "every unit" - see above). This gives you flexibility and ability to refactor and restructure the code any time you want, without the risk of changing the external behavior of the units. The second group are additional tests (like integration, smoke, white-box, regression tests etc.) - because they test larger parts of the system, they are substantially less numerous. They are important, because unit tests can't verify all interactions between the components, but they test only some of possible scenarios.