Как писать тесты для стороннего программного обеспечения, такого как Redis? - PullRequest
0 голосов
/ 01 апреля 2019

Я не уверен, что это правильный форум, чтобы задавать этот вопрос, если не любезно, направьте меня в правильном направлении.

Я хотел создать библиотеку / клиент для стороннего инструмента, который похож на redis.А что касается модульных / интеграционных тестов, я вижу, что в библиотеке predis есть тесты, которые напрямую взаимодействуют с работающим экземпляром redis, и есть тесты, использующие макеты.

Так что мойвопрос в том, нормально ли мне писать тесты, работающие на реальном экземпляре стороннего инструмента, или я должен использовать макеты полностью?

1 Ответ

1 голос
/ 01 апреля 2019

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

Правильно ли работает программное обеспечение сторонних производителей

Вы можете написать тест для сторонней библиотеки и рассматривать инструмент как черный ящик , поэтому вы не тестируете внутреннее устройство , но если оно ведет себя последовательно. Псевдокод такого теста

//testing if a value is automatically timestamped
expected = "expected value"
tool.setValue("myKey", expected)

actual = tool.getValue("myKey")

assertThat(actual, endsWith(expected))
assertThat(actual, startsWith(dateToday()))

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

Правильно ли работает ваш код

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

Вот пример псевдокода того, как будет выглядеть тест:

//check your code inserts the correct values without modifying them
mockTool = mock(SomeThirdPartyTool)
testInstance = new MyClass(mockTool)

expected = "some value"
expect(mockTool.insertValue()).toBeCalledWith(expected)

testInstance.insertValue(expected)

assertThat(expectationSatisfied())

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...