что такое голден тестирование
Introduction to golden testing
Published on December 4, 2017
Golden tests are like unit tests, except the expected output is stored in a separate file. I learned about them in 2010 from Max Grigorev at ZuriHac.
Let’s say you want to test Python’s json module. One way to do that would be to encode an object and compare the result to a reference string:
Alternatively, you could create a file with contents
and read it to know the expected output:
The file example1.json is called a golden file.
Here are some advantages of golden tests over ordinary unit tests:
If the expected output is large in size, it may be impractical to put it inside the source code.
No need to escape quotes or binary data in the expected output.
When you add a new test, your testing framework can generate the missing golden file from the current output of the function.
It is best if you can write down the expected output without looking at the actual output, but it is not always possible. The output may be too big to type it character by character, or it may be hard to predict. For instance, in the json example, you couldn’t tell in advance whether there would be spaces between array elements or not. So often what you do is launch an interactive interpreter (if your language of choice even has one), run the function, and then copy-paste its output into the test code.
This process can be easily automated if you use golden files.
The expected output can be automatically updated.
Say you changed your json module to replace some of the spaces with newlines to make the output more aesthetically pleasing. You have 40 test cases that need updating. Can you imagine doing this by hand?
With golden tests, you can tell your test framework to update all golden files from the current outputs, then check git diff to ensure that all changes are valid, and commit them.
If some of your tests suddently started failing, you can use diff or other such tools to compare the golden file to the actual file and figure out what exactly changed. Perhaps your testing framework could even show the diff automatically on test failure?
While advantages 1-2 are automatic, 3-5 require special support from your testing framework. The rest of this article will be focused on a Haskell testing framework tasty and its add-on package for golden tests, tasty-golden.
Basic usage
To illustrate how tasty-golden works, consider this yaml-to-json conversion module:
Because JSON contains quotes and YAML spans multiple lines, it is not very practical to store them as string literals in the source code file. Instead, you will keep them both in files.
Note that the name “golden file” only refers to the file containing the output, not the input. There is no requirement that the input is stored in a file or that there even is any “input” at all; but in practice it is often convenient to store them both in files so that there is an input file for every output file and vice versa.
This is all the code you need to support one, two, or a thousand test cases. When run, this code will:
Now run your test suite (note: in a proper cabalized project, you’d run cabal test or stack test instead):
tasty-golden realized that this is a new test case because the golden file was absent, so it went ahead and initialized the golden file based on the function’s output. You can now examine the file to see if it makes sense:
If you are happy with it, check in both input and output files to git. This is important so that your collaborators can run the tests, but it also helps when dealing with failing tests, as you’ll see next.
Dealing with test failures
Occasionally, your tests will fail. A test that cannot fail is a useless test.
A golden test fails when the actual output does not match the contents of the golden file. You then need to figure out whether this is a bug or an intentional code change.
Let’s say you decide that the output of yamlToJson should end with a newline.
The new function definition is
Now run the test suite:
Now, because your golden file is tracked by git, you can examine the differences between the old and new golden files with git diff :
Because this is the change you expected, you can now commit the updated file to git.
СОДЕРЖАНИЕ
В медицине
«Золотой стандарт» может относиться к критериям, по которым оцениваются научные данные. Например, в исследованиях по реанимации «золотой стандарт» теста лекарства или процедуры заключается в том, приводит ли она к увеличению числа неврологически здоровых выживших, которые покидают больницу. Другие виды медицинских исследований могут рассматривать значительное снижение 30-дневной смертности как золотой стандарт.
На практике, однако, использование этого термина авторами, а также его соблюдение со стороны редакций заметно невысокое, по крайней мере, для журналов AMA.
Гипотетический идеальный тест «золотого стандарта» имеет чувствительность 100% в отношении наличия заболевания (он выявляет всех людей с четко определенным процессом болезни; он не дает ложноотрицательных результатов) и специфичность 100%. (он не идентифицирует ложно кого-либо с условием, у которого нет условия; он не дает ложноположительных результатов). На практике иногда не бывает истинных тестов по золотому стандарту.
Тестовая калибровка
Поскольку тесты могут быть неправильными (давать ложноотрицательные или ложноположительные ), результаты следует интерпретировать в контексте анамнеза, физических данных и других результатов тестов у испытуемого. Именно в этом контексте определяется чувствительность и специфичность теста «золотой стандарт».
Когда золотой стандарт не идеален, его чувствительность и специфичность должны быть откалиброваны по более точным тестам или по определению состояния. Эта калибровка особенно важна, когда точный тест доступен только при вскрытии. Важно подчеркнуть, что тест должен соответствовать некоторому соглашению между наблюдателями, чтобы избежать некоторой предвзятости, вызванной самим исследованием.
Двусмысленность
Иногда «тест золотого стандарта» относится к самому эффективному из доступных тестов. В этих случаях нет другого критерия, с которым его можно было бы сравнить, и это эквивалентно определению. Применительно к этому значению тесты по золотому стандарту обычно вообще не выполняются. Это связано с тем, что тест по золотому стандарту может быть трудным или невозможным для живого человека (т. Е. Тест проводится как часть вскрытия или может занять слишком много времени, чтобы результаты теста стали доступны клинически. полезный).
Для чего нужны «золотые сигналы» мониторинга и SRE?
Прим. перев.: То, что сегодня принято называть SRE (Site Reliability Engineering — «обеспечение надежности информационных систем»), включает в себя большой спектр мероприятий по эксплуатации программных продуктов, направленных на достижение ими необходимого уровня надежности. Мониторинг — одно из ключевых мероприятий, а «золотые сигналы» образуют главные метрики, которые должны в нём учитываться. Не найдя на Хабре ни одного материала про них, мы решили перевести небольшую заметку от авторов платформы для управления инцидентами (VictorOps), дающую представление общее представление об этом подходе.
Эффективный site reliability engineering (SRE) опирается на глубокое понимание базовой инфраструктуры сервиса и архитектуры. Повышение прозрачности состояния приложения и инфраструктуры — это только начало проактивной работы над созданием надежных систем. При этом наилучшей отправной точкой для мониторинга состояния систем считаются так называемые «четыре золотых сигнала» (four golden signals) SRE. Наладив эти четыре базовых метода мониторинга, можно переходить к дальнейшему повышению прозрачности системы.
Повышение прозрачности вкупе с эффективными методами совместной работы позволяет командам SRE оперативно отслеживать работу систем и принимать меры для устранения последствий инцидентов, повышая общую эффективность методов мониторинга и оповещения. Золотые сигналы SRE помогают командам выявлять любые потенциальные слабые места в надежности, позволяя сосредоточиться над устранением проблем в инфраструктуре. Давайте же исследуем взаимосвязь между методами мониторинга и командами SRE и посмотрим, какое влияние золотые сигналы оказывают на процесс.
Мониторинг и SRE
В III части нашего DevOps-словаря мы исследовали интернет, пытаясь найти определение SRE. Согласно соответствующей статье в Wikipedia, «Ben Treynor, основатель Site Reliability Team в Google [говорит], что SRE — „это то, что получается, когда software engineer занимается тем, что раньше называлось эксплуатацией“». SRE сочетает задачи и возможности программной инженерии с проблемами эксплуатации IT и помогает находить решения для вопросов, связанных с надежностью. Понятно, что команды SRE должны мониторить свои сервисы для выявления областей, в которых можно повысить надежность.
Именно в этом и заключается задача мониторинга применительно к командам SRE. Он занимает лишь небольшую часть в создании высокопрозрачных систем, однако это важный элемент для понимания состояния приложений и инфраструктуры. Четыре золотых сигнала мониторинга и SRE обеспечивают базовый уровень прозрачности в отношении надежности всего, что вы создаете. Достигнув комфортного уровня наблюдаемости состояния золотых сигналов, можно использовать эту дополнительную информацию для более углубленного анализа с помощью инструментов для мониторинга.
Теперь, когда мы определились с важностью мониторинга золотых сигналов SRE, давайте обратимся к реальным метрикам, составляющим их.
Четыре золотых сигнала мониторинга
В начале пути по совершенствованию усилий по мониторингу бывает непросто понять, с чего следует начинать. Четыре золотых сигнала SRE и мониторинга впервые были приведены в книге Google о SRE, и в настоящее время активно используются многими командами. С них отлично начинать, поскольку они помогают выделить основные метрики, которые следует отслеживать всегда.
Итак, давайте рассмотрим золотые сигналы и разберемся, почему их мониторинг является неотъемлемым элементом в обеспечении надежности любой системы.
1. Задержка (Latency)
Сколько времени занимает обработка запроса? Определите ориентир для задержек, типичных для успешных запросов, и сравните его с задержками для неуспешных запросов. Отслеживание задержек, вызванных ошибками, позволяет решить любые вопросы, связанные со скоростью выявления инцидента и реакции на него.
2. Трафик (Traffic)
Этот сигнал не требует особых пояснений. Какое влияние на систему оказывает количество пользователей или число транзакций, проходящих через сервис? В зависимости от функциональности сервиса измерение трафика может существенно отличаться от компании к компании. Отслеживая взаимодействие с реальными пользователями и трафик, можно лучше понять, как конечные пользователи воспринимают сервис, и получить представление о том, как системы ведут себя в условиях стресса.
3. Ошибки (Errors)
Конечно, каждая команда должна следить за ошибками. Независимо от того, вызваны ли ошибки заданной вручную логикой или автономны (вроде неудавшегося HTTP-запроса), SRE-команды должны отслеживать их. Многие SRE-команды используют специальное ПО для управления инцидентами для оповещений о критических ошибках, поиска их причин и проведения работ по устранению последствий.
4. Насыщенность (Saturation)
Каждая команда должна следить за загруженностью своей системы. Важно задать метрику для насыщенности, которая бы означала, что сервис достиг максимума своих возможностей. Большинство сервисов начинают терять производительность еще до того, как загрузка достигнет 100%, поэтому понимание функциональности вашей собственной системы важно для определения ориентира насыщенности, который имеет смысл.
Установив правила мониторинга и оповещений для четырех золотых сигналов, вы охватите большинство ключевых инцидентов в системе. Однако чтобы приступить с созданию проактивной системы для мониторинга и SRE, придется копнуть еще глубже.
Прим. перев.: Как пример иллюстрации dashboard’а с графиками «золотых сигналов» приведём результат соответствующей конфигурации мониторинга для Kubernetes из этой статьи от Sysdig:
Прим. перев.: А вот более наглядное представление о золотых сигналах от Denise Yu, которую можно использовать как удобную памятку:
Проактивный SRE выходит за рамки золотых сигналов
Мониторинг золотых сигналов — отличное начало для анализа инцидентов в сервисе, однако его не достаточно. Опытные команды SRE проактивно изучают свои системы с помощью многочисленных дополнительных методов. Проводя организованные испытания на подготовительных этапах и в production, команды SRE активно изучают свои системы и используют получаемую информацию для повышения надежности сервисов.
Chaos Engineering
Хаос-инжиниринг — это дисциплина, применяемая командами для испытания своих систем с целью упреждающего обнаружения слабых мест и уязвимостей. Вручную вводя хаос в сервис, можно посмотреть, как именно система реагирует на различные обстоятельства.
Прим. перев.: Подробнее о таком подходе читайте в статье «Chaos Engineering: искусство умышленного разрушения» (часть 1 и часть 2).
Игровые дни (Game Days)
В то время как хаос-инжиниринг направлен на понимание системы, игровые дни помогают понять персонал. Они используются для проверки устойчивости команды, когда речь идет о реагировании на инциденты и устранении их последствий. Результаты игровых дней можно использовать для разработки более эффективных процессов или определения потребности в новых инструментах, повышающих эффективность персонала.
Синтетический мониторинг
Синтетический мониторинг позволяет командам создавать искусственных пользователей и имитировать их поведение с помощью сервиса. Можно задать определенные поведенческие паттерны и понаблюдать за тем, как система ведет себя в условиях данной нагрузки. Синтетический мониторинг — отличный метод для детального тестирования и определения надежности конкретных сервисов в рамках всей системы.
Любая команда, стремящаяся визуально отслеживать состояние системы, обязана следить за золотыми сигналами SRE. Но представление о состоянии и общей надежности системы — вовсе не то же самое, что работа над повышением ее надежности. В современной экосистеме высокораспределенных систем и стремительного развертывания перед командами SRE стоит непростая задача. Золотые сигналы мониторинга и SRE могут стать той отправной точкой, с которой начнется дальнейшее совершенствование в рамках SRE.
Flutter: Golden tests — compare Widgets with Snapshots
Testing is very important to deliver apps with the best quality. In this article, I’d like to tell about one of the less known features of Widget test — Golden tests.
What is Golden test?
Golden tests are basically Widget tests. A special mather compares your widget with an image file and expects that it looks the same.
Golden files are image files that were created from a manually verified widget.
How to create Golden test?
For the sake of example let’s create a golden test for Flutter’s “Hello World” app.
In Flutter project test folder we create golden_widget_test.dart with the following code:
As you see, you start creating your Golden test as a usual Widget test by pumping your widget.
Once the widget is pumped, it is compared with the image:
How to generate Golden files?
Now it is time to generate these manually verified images. If you’d like to generate images for all your Golden tests (or update old ones), run:
the main.png file should appear in your project test folder. Do not forget to add it to version control.
For only one particular test you can run:
How to run tests?
You can run tests now as normal unit tests to verify that generated Golden files match your widget.
Complete Sample
Golden tests are helpful to check that your widgets look as expected. It doesn’t have to be the whole screen. You can create your Golden test for a part of UI as well. If in a while you change your UI, don’t forget to generate new images 😉
ksheremet/golden_test
Contribute to ksheremet/golden_test development by creating an account on GitHub.
Underhood
When you generate images, LocalFileComparator (the default Golden File comparator) is used to create/update the files on disk to match the rendering. When you run a test, LocalFileComparator loads the image file from the local file system and performs a simplistic byte-to-byte comparison of the encoded PNGs. It returns true if there is an exact match. Even though your files represent the same pixels, but are encoded differently, the test will fail.
You can override default comparator by implementing yours. For this, your comparator needs to extend class GoldenFileComparator. Then you assign an instance of that class to goldenFileComparator. The code snippet looks like this: