Страницы

Поиск по вопросам

четверг, 13 февраля 2020 г.

Как проще всего сымитировать репозиторий (данные)

#c_sharp #repository #mocking


У меня есть интерфейс репозитория, например:

public interface IUserRepository
{
    IEnumerable ListUsers();
    User GetUserById(int id);
    void AddUser(User user);
    void DeleteUser(User user);
    void EditUser(User user);
}


где User, например, выглядит так:

public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public IEnumerable { get; set; }
    public string Email { get; set; }
} 


на всякий случай, 

public class Role 
{
    public int Id { get; set; }
    public string Name { get; set; }
}


Как проще всего сделать имитацию данного репозитория с фейковыми данными?


Если просто сделать singleton внутри которого определить List, то это меня
смущает, потому что будут отличия в поведении от реального репозитория. Если в реальном
репозиторие два раза сделать GetUser(id) (с одним и тем же id), то получим два экземпляра
объекта. А если в singleton-е или статическом классе так же будем 2 раза доставать
из List<>, то получаем один экземпляр объекта.
Если делать Text File или XML, то вроде как долго. Хотелось бы максимально простой
вариант найти. Но если это самый простой вариант, то скажите, тогда сам отвечу, что
получилось. Что касается SQLite, то тем более городить долго, не стоит того. 
Если использовать Моки, то смущает, что у меня почти нет с ними опыта работы, и то,
что данные (например, имя, Email) будут выглядеть не красиво. Кажется, в моей ситуации
проще самому ввести как-то данные для 5-10 пользоватей. 


UPDATE: Сохранять состояние достаточно в рамках одного сеанса работы программы. После
ее выключения, можно сбрасывать добавленных или измененных User-ов
    


Ответы

Ответ 1



Статический класс, но отдавать и сохранять в нём всегда копии объектов, а не сами объекты. Естественно, имеются в виду глубокие копии.

Ответ 2



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

Комментариев нет:

Отправить комментарий