Задать вопрос

HellWalk

Ответы пользователя по тегу PHPUnit

  • А как тестировать handler?

    @HellWalk
    Если говорить не о чистых юнит тестах (они замороченные), а функциональном тестировании (на базе того же функционала phpunit), то:

    Я не могу проверить, что попало в базу, потому что я не знаю Id, по которому туда попадут значения


    Но вы же знаете название добавляемого города - по нему и проверьте, появился ли такой город в базе.

    P.S.
    У вас там сущности можно оптимизировать - как понимаю вы там каждый раз uuid и дату создания передаете в конструктор, можно сделать трейты раз два, и в сущности указывать:

    /**
 * @ORM\Entity(repositoryClass=PostRepository::class)
 * @ORM\HasLifecycleCallbacks()
 */
class Post
{
    use IdTrait;
    use CreatedAtTrait;

   // ...


    Двумя строчками в сущности добавляете два поля и их автоматическое заполнение. Избавите конструктор от двух параметров.
    Ответ написан
    Комментировать
    Комментировать

  • Как исправить конфигурационный файл phpunit.xml?

    @HellWalk
    Вот пример рабочего phpunit.xml:

    <?xml version="1.0" encoding="utf-8"?>
<phpunit bootstrap="./vendor/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Test Suite">
            <directory>./tests</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist>
            <directory suffix=".php">./src/</directory>
        </whitelist>
    </filter>
</phpunit>
    Ответ написан
    Комментировать
    Комментировать

  • Какой смысл mock объектов для юнит тестирования своего кода?

    @HellWalk
    Смысл моков - эмулировать объекты с определенным поведением.

    Самый банальный пример, помимо http запросов, это эмулирование неправильных объектов.

    Допустим, у вас есть сервис, который обрабатывает какой-то объект. Объект написан хорошо, с валидацией данных, и его поведение корректное. Но чтобы вам написать качественный сервис - он не должен полагаться на то, что другой объект ведет себя корректно. Он должен дополнительно проверять граничные ситуации. И разумеется, на такие кейсы нужно написать тесты, а как их написать, если тестируемый объект написан так, что он ведет себя корректно? Вот здесь и приходят на помощь моки.

    В phpunit есть функционал подсчета покрытия кода тестами - попробуйте на каком-нибудь относительно небольшом модуле добиться 100% покрытия кода тестами - вам обязательно придется использовать хитрые моки, эмулирующие нестандартное поведение объектов.

    P.S. Если вы недавно знакомы с юнит-тестами - непонимание моков нормально. Если будете стремиться писать надежный код, с качественным покрытием кода тестами (здесь самое сложное - предугадать все плохие кейсы, которые будут пытаться сломать ваш код) - понимание придет.
    Ответ написан
    2 комментария
    2 комментария