//Что такое МОК?
            //Мок это объект у которого тип и поведение определяется прямо в рантайме.

            //

            // Так мы создаем обычный мок без поведения. Он создает видимость что объект является IRepository<Project,int>, хотя на деле это лишь пустышка.
            IRepository<Project,int> mockedProjectRepository = Mock.Of<IRepository<Project, int>>();


            // Так мы создаем мок с поведением. Это будет проектный репозиторий. Причем если на нем вызвать метод Find и в качестве аргумента передать любую инстанцию GetProjectWith, то он вернет наш
            // заранее определенный массив проектов. Еще раз - на самом деле это не репозиторий, а лишь пустышка, которая знает что ей нужно вернуть
            var projects = new[]
            {
                new Project()
                {
                    Title = "Project "
                }
            };

            IRepository<Project, int> mockedProjectRepository2 = Mock.Of<IRepository<Project, int>>
                (mock=>
                    mock.Find(It.IsAny<GetProjectWith>()) == projects
                );

            // А вот так например, мы можем добавить еще и правило для вызова Get

            IRepository<Project, int> mockedProjectRepository3 = Mock.Of<IRepository<Project, int>>
                (mock =>
                    mock.Find(It.IsAny<GetProjectWith>()) == projects &&
                    mock.Get(It.IsAny<int>()) == new Project() // Вызов Get вернет новый проект
                );



            //Зачем нужны моки?
            //Суть юнит-тестов в слове юнит - единица. Если у тебя в юнит тесте учавствует больше чем одна единица поведения, то это уже интеграционный тест.
            //Классы которые не имеют поведения (например модели как Project) в счет не идут.

            //Зачем нужны моки в наших тестах?
            //Каждый Экшн опирается на зависимости. Их можно легко вычислить, если перейти в класс и постреть пропы с атрибутом Include.
            //Например класс CreateCategoryAction опирается на
            // [Inject] public IRepository<Project, int?> ProjectRepository { private get; set; }
            // [Inject] public IRepository<Category, int?> CategoriesRepository { private get; set; }
            //
            // Это значит что нам понадобится 2 мок-объекта.
            // Как определить, какое поведение прикрутить к мокам?
            // Это уже не так тривиально и зависит от того что мы тестируем.
            //
            // В этом тесте мы хотим протестировать то, что категория была создана и сохранена.
            //
            // Тоесть нам нужно
            // А. Создать !инстанцию! CreateCategoryAction (ни в коем случае не мок - мы хотим тестировать реальный код, а не пустышку)
            // B. Создать 2 мок-объекта для репозиториев Проекта и Категории
            // С. У мок объектов нужно так определить поведение, чтобы в CreateCategoryAction все данные прошли валидацию
            // D. Еще нам нужные побочные данные - Айди пользователя который вызывает Action (ExecutorID), а так же инстанция проекта, наполненая данными, которые важны для валидации
            //      например у него в модераторах должен быть пользователь с ExecutorID
            // E. Теперь нам нужно сделать тупо createCategoryAction.ProjectRepository = mockedProjectRepository и тоже самое для CategoryRepository
            // F. Вызвать createCategoryAction.Execute(input) где инпут - это наши прямые входные данные
            // G. Экшон вернет категорию, и нам нужно поставить Assert на правильность данных
            // H. Наконец нужно проверить что Экшон вызвал метод Save на CategoryRepository