Mock-объект

[Николай Мельков]

Разбираюсь с модульным тестированием. Возникла сложность в описании Mock-объекта репозитория со следующей логикой

        [TestMethod]
        public void CanFindOrdersViaCustomer()
        {
            Customer customer = new Customer();
            repository.Add( 42, customer );
            repository.Add( 12, new Customer() );
            repository.Add( 3, customer );
            repository.Add( 21, customer );
            repository.Add( 1, new Customer() );

 

            Assert.AreEqual( 3, repository.GetOrders( customer ).Count );
        }

 

[Alexander Byndyu]

Николай,

Опишите подробнее в чем сложность. Если можно, то хочет увидеть код репозитория (его интерфейса) и Custormer.

--

Best regards,
Byndyu Alexander

Phone: +7 (904) 305 5263
Skype: alexander.byndyu
Blog: http://blog.byndyu.ru
Twitter: alexanderbyndyu

27 июня 2012 г., 10:13 пользователь Николай Мельков <nik...@gmail.com> написал:

[Николай Мельков]

Следующий интерфейс

   public interface IOrderRepository
   {
       void Add( int orderNumber, Customer customer );
       IList<Order> GetOrders( Customer customer );
   }

Я только начинаю изучать Mock-объекты. Хотел эмулировать такое поведение, когда в mock-объекте изначально задано начальное состояние (5 отчетов от разных заказчиков). И необходимо протестировать возврат списка отчетов определенного заказчика.

Customer - на данном этапе пустой.

Похоже я занимаюсь тестированием тестирования, пытаясь поместить все поведение в Mock-объект.

27 июня 2012 г., 10:23 пользователь Alexander Byndyu <alexande...@gmail.com> написал:

[Ilya Dubadenko]

Николай, если вы замокаете репозиторий в тесте CanFindOrdersViaCustomer, то тест будет лишен смысла, так как он будет проверять то, как вы написали mock, но не бизнес логику. Тестировать mock-объекты не надо. Рекомендую вообще не мокать объекты типа репозитория или uow, лучше использовать inmemory хранилища.

среда, 27 июня 2012 г. пользователь Николай Мельков <nik...@gmail.com> писал:

[Николай Мельков]

Спасибо за ответы. Я не стой стороны взглянул на тесты. В данном случае мне стоило "mock'ать" Customer, и его метод Equal(o).

Пока не ясно представляю какие типы имитаций позволяют делать mock-объекты.

воскресенье, 1 июля 2012 г., 14:16:16 UTC+6 пользователь Ilya Dubadenko написал:

[Ilya Dubadenko]

В основном мокается результат вызова метода, свойства (например, метод getcount() при вызове возвращает 5, или другой очень сложный алгоритм, результат работы которого известен на нескольких примерах). На самом деле такое поведение можно и не мокать, а написать stub. Кстати, это важный момент отказа от mock в пользу stub. Ощутимая польза от mock объекта может быть если вы проверяете поведение (например, что какой-нибудь метод был вызван при определенных условиях, так называемые методы verify).


воскресенье, 1 июля 2012 г. пользователь Николай Мельков <nik...@gmail.com> писал: