Определение «эффективных» модульных тестов для сервисного фасада

Question

Учитывая следующий (базовый) класс фасадов услуг, я хотел бы получить некоторые рекомендации и указания о том, какие юнит-тесты следует и стоит написать.Я использую MEF для внедрения зависимостей и AutoMapper для сопоставления объектов моих объектов контрактам данных с объектами домена и наоборот.

public sealed class MyServiceFacade
{
    [ImportingConstructor()]
    public MyServiceFacade(IDependency dependency,
                           IMappingEngine mappingEngine)
    {
        if (dependency == null)
            throw new ArgumentNullException("dependency");

        if (mappingEngine == null)
            throw new ArgumentNullException("mappingEngine");

        Dependency = dependency;
        MappingEngine = mappingEngine;
    }

    public IDependency Dependency { get; private set; }
    public IMappingEngine MappingEngine { get; private set; }

    public ResponseContract TheMethod(RequestContract requestContract)
    {
        // Verify parameters
        if (requestContract == null)
            throw new ArgumentNullException(requestContract);

        // Translate parameter values
        var request = MappingEngine.DynamicMap<Request>(requestContract);

        // Delegate to the domain layer
        var response = Dependency.DoSomethingWith(request);

        // Translate the response
        var responseContract = MappingEngine.DynamicMap<ResponseContract>(response);

        // Return the response
        return responseContract;
    }
}

Я хотел бы видеть хорошее покрытие кода, но не хочуписать тесты, которые не являются полезными / эффективными.

(Предложения по эффективным интеграционным тестам также будут полезны.)

Ваши мысли?

ОБНОВЛЕНИЕ

Основываясь на ограниченных ответах, я подумал, что я продолжу и продолжу разговор немного больше (чего я изначально старался избегать), описав то, что я считаю сценарием «наихудшего случая».

Один из разработчиков в моей команде является активным сторонником модульного тестирования «белого ящика» с максимально широким охватом кода.В результате его подхода у нас будут следующие тесты:

1. Когда объект конструируется, если свойство 'dependency' равно null, выдается исключение ArgumentNullException.
2. При создании объекта, если свойство 'mappingEngine' имеет значение null, выдается исключение ArgumentNullException.
3. При создании объекта, если оба аргумента не являются нулевыми, исключение ArgumentNullException не выдается.
4. После того, как объект создан, свойство Dependency возвращает объект, переданный в параметре 'dependency' конструктору.
5. После того, как объект создан, свойство MappingEngine возвращает объект, переданный в параметре 'mappingEngine', вконструктор.
6. Когда вызывается TheMethod, если свойство requestContract имеет значение null, генерируется исключение ArgumentNullException.
7. Когда вызывается TheMethod, если свойство requestContract не имеет значение null,ArgumentNullException не генерируется.
8. Когда вызывается метод, thМетод DynamicMap () в mocked IMappingEngine вызывается только один раз, а RequestContract передается в TheMethod.
9. Когда вызывается TheMethod, метод MoSedeWith () в mocked IDependency вызывается только один раз, а объект Request возвращается изmocked IMappingEngine.
10. Когда вызывается TheMethod, метод DynamicMap () смоделированного IMappingEngine вызывается только один раз с объектом Response, возвращаемым из смоделированной IDependency.
11. Когда вызывается TheMethod,Возвращается объект ResponseContract, возвращаемый из смоделированного IMappingEngine.

Как видите, это приводит к большому количеству тестов, которые действительно проверяют реализацию и не отражают требования более высокого уровня (другой подход ктаблица).

Так вы подходите к тестированию или идете другим путем?

Answer 1

Я хотел бы получить некоторые рекомендации и указания о том, какие юнит-тесты следует и стоит написать

Я использую эквивалентное разбиение , чтобы предложить набор базовых тестов, обеспечивающих хорошее покрытие.