TaskCompletionSource не создает [дубликат]

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

Тестирование модуля

За последние два года я написал проект хобби, и я не писал для него модульные тесты. После того, как я написал около 50 тыс. Строк, я узнал, что действительно нужно будет писать модульные тесты. Я не использовал интерфейсы (или очень экономно) ... и когда я сделал свой первый модульный тест, я узнал, что это сложно. Почему?

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

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

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

public interface IPricable
{
    int Price { get; }
}

public interface ICar : IPricable

public abstract class Article
{
    public int Price { get { return ... } }
}

public class Car : Article, ICar
{
    // Price does not need to be defined here
}

Таким образом, копирование кода не требуется, но при этом полезно использовать автомобиль в качестве интерфейса (ICar).