Что такое тестирование снимков и действительно ли это в PHP?

Возможно, вы слышали о таких вещах, как Selenium и Behat ? Я не хочу останавливаться на них слишком много. Давайте просто скажем, что Selenium — это инструмент, который мы можем использовать, чтобы притвориться браузером, а Behat — удобный для бизнеса язык для написания таких претензий.

К сожалению, многие тесты на основе браузера могут быть хрупкими. Это связано с точной структурой разметки и не обязательно связано с логикой, которая генерирует разметку.

Тестирование снимков — это другой подход к тому же. React побуждает думать обо всем интерфейсе с точки зрения мельчайших частей, на которые он может быть разбит. Вместо того, чтобы собирать всю корзину, она поощряет разбивать вещи на отдельные части; нравиться:

• каждый продукт
• список продуктов
• детали доставки
• индикатор прогресса

При создании каждой из этих частей мы определяем, какой должна быть разметка и стили, учитывая любую исходную информацию. Мы определяем это путем создания метода render

 class Tweets extends React.Component {
  render() {
    return (
      <div className="tweets">
        {props.tweets.map((tweet, i) => {
          return (
            <Tweet {...tweet} key={i} />
          )
        })}
      </div>
    )
  }
}

… или путем определения простой функции, которая будет возвращать строку или React.Component Предыдущие примеры продемонстрировали функциональный подход.

Это интересный способ думать об интерфейсе. Мы пишем render

И именно этот способ мышления приводит к простейшему способу тестирования компонентов React: тестированию моментальных снимков. Подумайте об этом на минуту …

Мы строим компоненты React для визуализации самих себя, учитывая любую исходную информацию. Мы можем проработать все возможные входы в нашей голове. Мы даже можем определить строгую проверку того, какую исходную информацию (или свойства) мы допускаем в наши компоненты.

Итак, если мы сможем проработать эти сценарии при разработке нашего компонента: тогда мы сможем проработать их в тесте. Давайте создадим новый компонент:

 const Badge = function(props) {
  const styles = {
    "borderColor": props.borderColor
  }

  if (props.type === "text") {
    return (
      <div style={styles}>{props.text}</div>
    )
  }

  return (
    <img style={styles} src={props.src} alt={props.text} />
  )
}

Это наш компонент Badge Это может быть двух типов: textimage Он также может иметь цвет границы. Мы можем проверить и создать значения по умолчанию для этих свойств:

 const requiredIf = function(field, value, error) {

  // custom validators expect this signature
  return function(props, propName, componentName) {

    // if props.type === "image" and props.src is not set
    if (props[field] === value && !props[propName]) {

      return new Error(error)
    }
  }
}

Badge.propTypes = {
  "borderColor": React.PropTypes.string,
  "type": React.PropTypes.oneOf(["text", "image"]),
  "src": requiredIf("type", "image", "src required for image")
}

Badge.defaultProps = {
  "borderColor": "#000",
  "type": "text"
}

Итак, как можно использовать этот компонент? Есть несколько вариантов:

• Без указания borderColortype
• Изменение typeimagesrc
• Изменение borderColor

Это начинает звучать как тест. Что если мы назвали визуализированный компонент с четко определенным начальным набором данных моментальным снимком? Мы могли бы описать эти сценарии с помощью некоторого JavaScript:

 import React from "react"
import Tweets from "./tweets"

import renderer from "react-test-renderer"

test("tweets are rendered correctly", function() {
  const defaultBadge = renderer.create(
    <Tweets>...</Tweets>
  )

  expect(component.toJSON()).toMatchSnapshot()

  const imageBadge = renderer.create(
    <Tweets type="image" src="path/to/image">...</Tweets>
  )

  expect(component.toJSON()).toMatchSnapshot()

  const borderedBadge = renderer.create(
    <Tweets borderColor="red">...</Tweets>
  )

  expect(component.toJSON()).toMatchSnapshot()
})

Нам нужно настроить Jest , прежде чем мы сможем запустить этот код.

С каждой модификацией начальных свойств может быть представлен новый набор разметки. Мы должны проверить, что каждый вариант соответствует снимку, который мы знаем, чтобы быть точным.

При этом мы можем видеть, что тестирование моментальных снимков — это средство, с помощью которого мы можем предсказать вывод данной функции (или внутреннее состояние заданного объекта) и сравнить будущие результаты с ней. С четко определенным планом данных, которые мы ожидаем, что наш код даст, мы можем легко определить, когда результат является неожиданным или неправильным.

У этого есть старое имя: Тестирование характеристик . Мы пишем тесты с характеристиками (или снимками), устанавливая правильно сформированный ожидаемый результат. Последующие тесты сравнивают вывод нашего кода с базовой линией, используя те же входные данные.

Теперь давайте подумаем о сценариях, где это может быть полезно для нас …

Тестирование снимков в PHP

Мы рассмотрим несколько вариантов использования для тестирования снимков. Прежде чем мы это сделаем, позвольте мне представить вам плагин для тестирования снимков PHPUnit: https://github.com/spatie/phpunit-snapshot-assertions

Вы можете установить его через:

 composer require --dev spatie/phpunit-snapshot-assertions

Он предоставляет ряд помощников в виде:

 use PHPUnit\Framework\TestCase;
use Spatie\Snapshots\MatchesSnapshots;

class ExampleTest extends TestCase
{
  use MatchesSnapshots;

  public function testExamples()
  {
    $this->assertMatchesSnapshot(...);
    $this->assertMatchesXmlSnapshot(...);
    $this->assertMatchesJsonSnapshot(...);
  }
}

Эти методы создают файлы снимков того же типа, что и Jest. В общем, нам нужно использовать только первый, но второй и третий генерируют более интересные различия для их соответствующих типов контента.

Шаблоны

Первое и довольно очевидное использование для этого — в тестировании шаблонов. Чем меньше наших шаблонов, тем проще будет написать для них тестовые снимки. Это особенно полезно при использовании шаблонизаторов, которые принимают начальные свойства:

 <div class="tweet">
  <img src={{ $user->avatar }} />
  <div class="text">
    <div class="handle">{{ $user->handle }}</div>
    <div class="content">{{ $content }}</div>
  </div>
</div>

 Route::get("/first-tweet", function () {
  return view(
    "tweet", Tweet::first()->toArray()
  );
});

Понятно, что шаблон должен производить, учитывая повторяемую исходную информацию. Мы могли бы даже посмеяться над начальными данными и подтвердить вывод:

 namespace Tests\Unit;

use Spatie\Snapshots\MatchesSnapshots;
use Tests\TestCase;

class ExampleTest extends TestCase
{
  use MatchesSnapshots;

  public function testTweetsRenderCorrectly()
  {
    $user = new User();
    $user->avatar = "path/to/image";
    $user->handle = "assertchris";

    $tweet = new Tweet();
    $tweet->user = $user;
    $tweet->content = "Beep boop!";

    $rendered = view(
      "tweet", $tweet
    );

    $this->assertMatchesSnapshot($rendered);
  }
}

Я показываю примеры из приложения Laravel (купите наш вводный курс здесь !). Laravel использует PHPUnit под капотом, поэтому примеры будут работать и за пределами Laravel, с достаточной модификацией. Laravel является полезной отправной точкой, потому что он поставляется с механизмом шаблонов , маршрутизацией и ORM.

Событие Sourcing

Архитектура Event Sourcing особенно хорошо подходит для тестирования моментальных снимков. Их много, так что не стесняйтесь читать их !

Основная идея Event Sourcing заключается в том, что база данных доступна только для записи. Ничто не удаляется, но каждое значимое действие ведет к записи события. В отличие от большинства приложений CRUD, которые свободно создают и удаляют последнее состояние записей, приложения Event Source добавляют записи, которые представляют все действия.

 // continuing from sitepoint.com/event-sourcing-in-a-pinch...

$events = [
  new ProductInvented(...),
  new ProductPriced(...),
  new OutletOpened(...),
  new OutletStocked(...),
];

$this->assertMatchesSnapshot($events);

$projected = project($connection, $events);

$this->assertMatchesSnapshot($projected);

 php artisan queue:table
php artisan migrate

 return [
  "default" => env("QUEUE_DRIVER", "database"),
  // ...remaining configuration
];

 namespace Tests\Unit;

use Spatie\Snapshots\MatchesSnapshots;
use Tests\TestCase;

class ExampleTest extends TestCase
{
  use MatchesSnapshots;

  public function testQueueSomething()
  {
    // ...do something that leads to dispatch(new Job);
  }

  public function testQueueSomethingAgain()
  {
    // ...do something that leads to dispatch(new AnotherJob);
  }

  public function testQueue()
  {
    $table = config("queue.connections.database.table");
    $jobs = app("db")->select("select * from {$table}");

    $this->assertMatchesSnapshot($jobs);
  }
}