На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (16) « Первая ... 14 15 [16]  все  ( Перейти к последнему сообщению )  
> Rust vs C++ , очередная шляпа
    Цитата D_KEY @
    Но ты именно такой пример и приводил. У тебя было два интерфейса, но ты туда хотел подпихивать конкретные сущности.

    Не правда. Да у меня был пример с двумя интерфейсами, но упор я делал на то, что внутри метода, есть какой то вызываемый функционал, который ты не можешь съимиторовать через мок, вот мой пример:
    Цитата Wound @
    void testLinkToContainer()
    {
        /*Тут, вместо new даже может быть Mock, который будет делать все тоже самое, кроме физического создания контейнера в системе, например как в примере создавать эксземпляр класса, напихивать в него данные, возвращать его, но не сохранять в системе*/
        IContainer* pContainer = new COrgUnit(CN, DN, Location,...);
     
        /*Тут ровно тоже самое, создается либо через mock, либо напрямую нужный класс, забивается данными*/
        IPrincipal* pPrincipal = new Personage(CN, DN, Location,...);
     
        //! Допустим через интерфейс создаем юзер аккаунт, который нужен будет для линковки
        pPrincipal->CreateUserAccountPersonage();
     
        EntityLinker* linker = new EntiryLinker(...);
     
        //! Дальше тут какие то проверки, что все засетаплено честно.
     
        //! Дальше собственно выполняем нашу линковку:
        linker->LinkToContainer(pContainer, pPrincipal);
     
       /*Дальше идет тестирование результатов линковки*/
    }

    Видишь там вызов метода CreateUserAccountPersonage ? Под ним как раз и подразумевалось что у тебя чтобы например что то переместить, нужно выполнить реальный метод, а не моковый. Да, возможно я криво выразился, потому что не получается у меня сейчас сидеть думать как тебе написать чтоб ты понял, приходится в перерывах отвлекатся, но имелось ввиду то, что у тебя метод может содержать не просто какой то несвязанный функционал, а некую логику, которую ты не подсунешь в сам тестируемый метод. И дальше я тебе об этом писал:
    Скрытый текст
    Цитата Wound @
    Кого они проверяют? Я тебе говорю, что для какой то операции, необходимо вызвать какой то метод из этих классов явно/неявно.

    Цитата Wound @
    Могут, и чего? Я тебе пишу про то, что ты можешь в моке не учесть, какую то вещь, которая есть в используемом классе.
    Я не знаю, то о чем ты пишешь, больше напоминает тестирование несвязанного между собой функционала, например библиотечные функции какие нибудь. На практике же, довольно часто приходится работать с довольно связанными сущностями.

    Цитата Wound @
    У меня одна картина в голове стоит, у тебя вторая. Поэтому не понимаем друг друга. Ты мне пишешь про тестирование каких то несвязанных вещей, я напротив больше сталкивался с взаимосвязанными системами.
    Когда например у тебя один класс, инкапсулирует в себе кучу логики, которая инкапсулирует в себе другую кучу логики, которая инкапсулирует в себе еще какую то кучу логики.
    Я не знаю, может быть ты рассказываешь с философской точки зрения. Но хотел бы я посмотреть как ты все это тестировал бы.


    Цитата Wound @
    Но когда речь идет о какой то хитрой логике(не все же методы возвращают сумму двух чисел или например константную строку), то тут тебе придется мочить все сущности, которые используются в тестируемом алгоритме, а если вдруг какая то сущность внутри получается из другой сущности, или просто живет там, конструируясь на каких то данных, то придется в придачу еще и переписывать всю систему, то тут уж, извиняйте, но я понять не могу.


    Ты же мне, рассказываешь как я понял какую то философию программирования.
      Цитата Wound @
      Видишь там вызов метода CreateUserAccountPersonage ? Под ним как раз и подразумевалось что у тебя чтобы например что то переместить, нужно выполнить реальный метод, а не моковый.

      Вообще-то вместо вызова этого метода, ты должен был замокать UserAccountRepository или откуда там у тебя тестируемый метод данные берёт.
        Цитата korvin @
        Вообще-то вместо вызова этого метода, ты должен был замокать UserAccountRepository или откуда там у тебя тестируемый метод данные берёт.

        Так а если для получения результата внутритого метода есть еще логика, со своими типами и классами? Их тоже замокать? Я же и пишу, в итоге получится так, что тебе придется мокать вообще все. Да и не всегда прокидывают интерфейсы в метод. Бывает есть у тебя метод какой нибудь, который принимает контекст, а уже внутри из контекста - конструируются какие то типы, например с сервис локатора, или внутренней фабрики, либо на основе имеющихся данных, которые были получены путем других телодвижений.
        Сообщение отредактировано: Wound -
          Цитата Wound @
          Так а если для получения результата внутритого метода есть еще логика, со своими типами и классами? Их тоже замокать? Я же и пишу, в итоге получится так, что тебе придется мокать вообще все.

          Мокать нужно то, что инжектится как зависимость. Все внешние ресурсы (БД и т.п.) должны инжектиться или передаваться аргументами в метод, а следовательно мокаться.

          Цитата Wound @
          а уже внутри из контекста - конструируются какие то типы, например с сервис локатора

          Эти сервисы должны быть функциональными (т.е. получать внешние ресурсы в параметрах своих методов, а не хранить их в приватных полях), тогда их не нужно мокать, либо инжектиться и мокаться.
          Сообщение отредактировано: korvin -
            Цитата Wound @
            Так а если для получения результата внутритого метода есть еще логика, со своими типами и классами?

            Народ пишет про это:

            Цитата
            Очень часто наш код (функция, модуль) имеют внешние зависимости. Внешняя зависимость — это все, что делает ваши тесты не правдивыми и сложно-поддерживаемыми. Файловая система — зависимость: структура каталогов может быть другой на другой машине. База данных — зависимость, ее может не быть на другой машине. Веб-сервис — зависимость: может не быть интернета или может присутствовать фаервол и.т.д

            Если на вопрос: «будет ли этот компонент вести себя так же на другой машине?» вы отвечаете нет, то его необходимо “подменить” и тут вам на помощь как раз придут стабы и моки. Но есть и другая сторона медали, когда разработчик начинает увлекаться и приходит к тому, что подменяет вообще все. Соответственно тесты перестают проверять само приложение и начинают тестировать стабы, моки. Это в корне не верно. Если «живых» реализаций в тесте нет, то этот тест не тестирует ничего.

            Иногда эти термины stubs и mock путают: разница в том, что стаб ничего не проверяет, а лишь имитирует заданное состояние. А мок — это объект, у которого есть ожидания. Например, что данный метод класса должен быть вызван определенное число раз. Иными словами, ваш тест никогда не сломается из-за «стаба», а вот из-за мока может.

            user posted image

            С технической точки зрения это значит, что, используя стабы, мы проверяем состояние тестируемого класса или результат выполненного метода. При использовании мока мы проверяем, соответствуют ли ожидания мока поведению тестируемого класса. Также лучше использовать не более одного мока на тест. Иначе с высокой вероятностью вы нарушите принцип «тестировать только одну вещь». При этом, в одном тесте может быть сколько угодно стабов или же мок и стабы.
              Цитата JoeUser @
              Народ пишет про это:

              Народ немного странные вещи пишет. Например, что значит «не более одного мока на тест»? У тестируемого метода может быть больше одной внешней зависимости.

              Стабы используются в основном при функциональном тестировании, чтобы подменить внешние сторонние сервисы. В юнит-тестировании же стаб репозитория, например, вынужден будет реализовывать всю логику настоящего репозитория и может точно так же сломать тест, как и мок.
                Цитата Wound @
                Я же и пишу, в итоге получится так, что тебе придется мокать вообще все.
                Как бы да, на разве не в этом суть?
                Цитата Wound @
                а уже внутри из контекста - конструируются какие то типы, например с сервис локатора, или внутренней фабрики, либо на основе имеющихся данных, которые были получены путем других телодвижений.

                JoeUser, ты привёл классные ссылки, но мимо. Никакой мок (стаб) не должен нарушать инварианты, описанные в документаци.
                Сообщение отредактировано: Qraizer -
                  Цитата korvin @
                  Например, что значит «не более одного мока на тест»?

                  Зачем вырывать из контекста? Написано же "... также лучше использовать ...". Иными словами, если есть выбор.

                  Добавлено
                  Цитата Qraizer @
                  Никакой мок (стаб0 не должен нарушать инварианты, описанные в документаци.

                  Хм, а где в тексте ты узрел нарушение моками или стабами инвариантов, описанных в документации? :blink:
                  Сообщение отредактировано: JoeUser -
                    Цитата OpenGL @
                    Тогда как конкретно это делать?
                    Простейше? Тебе – и не только – вряд ли понравится: подменять можно лишь реализацию. Соответственно заголовки должны быть "боевыми".
                    0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                    0 пользователей:


                    Рейтинг@Mail.ru
                    [ Script execution time: 0,0433 ]   [ 15 queries used ]   [ Generated: 28.03.24, 19:39 GMT ]