Всем привет! Добро пожаловать на мой Телеграм канал. Меня зовут Александр. Здесь я планирую делиться интересными ресурсами на темы тестирования, автоматизации и инжиниринга сложных распределенных систем.

#paper #blockchain
Блокчейн системы не так-то просто тестировать.
Можно тестировать end-to-end взаимодействие с системой через различного рода кошельки.
Можно тестировать работу смарт контрактов и репликацию транзакций между нодами в сети.
Но один из самых важных аспектов тестирования блокчейн систем - это протоколы консенсуса (Proof Of Work, Proof of Stake, Proof of Elapsed Time и др.).
Различные системы конкурируют между собой, чтобы предложить более защищенные и быстрые протоколы.
Но как сравнить, что один протокол консенсуса лучше другого?
В данной работе описан подход к созданию блокчейн симулятора - который позволяет замерять базовые метрики "идеальной" системы и дальше изменять протоколы и смотреть как протоколы влиять на производительность системы.
https://digitalcommons.odu.edu/cgi/viewcontent.cgi?article=1050&context=vmasc_pubs
Под "базовыми" метриками, авторы понимают такие: пропусная способность (throughput), задержка (latency), отказоустойчивость (fault tolerance) и неоднородность (heterogeneity).
Симулятор “под капотом” запускает сеть узлов в виде отдельных Docker контейнеров.
Звучит интересно.

#testing #blockchain
Продолжая тему тестирования блокчейна. Я тут собираю список инструментов, видео, блог постов и академических работ по теме - https://github.com/alexromanov/awesome-blockchain-testing По мере свободного времени - изучаю их и буду готовить ревью). Если у Вас есть что-то интересное, чего нет в списке - делайте ПР, буду крайне рад.

Что значит “тестировать блокчейн”?

#testing #blockchain
Блокчейн - это “хайповая тема” последних лет. Каждый второй делает свою криптовалюту, каждый третий открывает криптовалютный обменник на углу.
Чтобы получше понять, зачем этот самый блокчейн нужен, очень рекомендую статью Вастрика на эту тему

Но что значит “тестировать блокчейн” ? Насколько глубокими и техническими должны быть знания тест инженера для работы с такими системами? Давайте разберемся вместе.

Тестирование блокчейна как системы.
Самый “хардкорный” вариант. В данном случае тестируется блокчейн сеть целиком - как целостное решение. Примеры - Bitcoin, Ethereum.
Тестируем:
- сохранение транзакций в блоки и связь между ними
- криптографические протоколы хеширования и генерация ключей
- репликацию данных между узлами в сети
- алгоритмы консенсуса
- производительность системы
- безопасность системы
- отказоустойчивость системы

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

Связь с блокчейном на бекенде происходит через API запросы. Часто это не HTTP REST API, а что-то более специфическое, такое как gRPC.
API может быть как сторонней системой вообще, так и просто узлом блокчейн сети, который развернут внутри системы.
Кроме того, остальные подходы к тестированию и автоматизации приложений - сохраняются:
- функциональное и нефункциональное тестирование
- UI / API тесты (и автотесты)

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

Основной аспект при тестировании - это использование специальных тестовых (TESTNET) блокчейн сетей для проведения транзакций. В таких сетях валюта технически такая же, как и реальная - но не стоит ничего.

Кроме того, могут быть еще и специфические виды кошельков в виде отдельных электронных устройств. А это отдельный интересный мир embedded девайсов.

Тестирование смарт контрактов и прочего DeFi.
Смарт контракты - это программный код, который релизует некую бизнес логику и загружен на блокчейн. Чаще всего под смарт контрактами имеют в виду код на языке Solidity в блокчейне Ethereum.

Тут подходы к тестированию как стандартные, так и необычные:
- юнит тесты
- функциональные тесты
- тесты безопасности

Необычность тестирования в том, что как только код отправлен в блокчейн (“задеплоен на прод”) - он начинает работать сразу. Его крайне сложно “остановить”. А уж удалить и “передеплоить” - так вообще невозможно.

Тестирование криптовалютных бирж
Биржы это обычно веб (или мобайл) приложения, который позволяют завести там аккаунт и заниматься торговлей и конвертацией разных криптовалют.
Очень похожи по своей сути на обычные сайты по банкингу и работе с валютой.

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

Как “быстро” проверить gRPC сервис?

#grpc #testing #tools
HTTP API приходится тестировать часто. Можно быстро сделать запрос с помощью cURL. Можно написать пару тестов на Java+RestAssured. Можно не усложнять - и использовать Postman.

Но что делать, когда надо быстро проверить работу сервиса, а он работает не по HTTP, а по gRPC? Как быть?

Postman судя по всему довольно криво поддерживает gRPC.
Генерировать клиент на основе протобафа и писать почти полноценный сервис для проверки одного-двух запросов - слишком долго и сложно.

На помощь приходит простой и удобный инструмент - grpcurl Он позволяет делать запросы на Ваши сервиса очень похоже, как бы Вы делали это с помощью cURL.
Перед использованием, убедитесь, что reflection включен на серверной стороне. Иначе, работать запросы не будут.

Для тех, кто не хочет связываться с терминалом - есть UI надстройка для grpcurl - gRPCox.

Почему gRPC тестировать несколько сложнее, чем обычный HTTP REST?

#grpc #testing
АПИ тестирование и автоматизация уже давно не “магия”. Львиную долю АПИ, которое проходится тестировать составляет HTTP REST. Изредка “завозят” что-то посложнее - например веб сокеты.

Когда тестировщик проводит проверку АПИ, тесты сводятся к следующим шагам:
1. Отправь один запрос (GET, POST, PUT, DELETE, etc) на сервер
2. Получи один ответ от сервера (в разумное время)
3. Проверь содержание ответа

Как валидация будет происходить (cURL’ом, Postman’ом, кодом) - не так важно.

В случае с gRPC ситуация несколько усложняется:
- данные передаются в бинарном виде. Значит просто так в консоли браузера запросы не посмотришь. (Нужен прокси).
- передача данных между клиентом и сервером в виде унарных запросов (один запрос - один ответ) - это лишь один из возможных вариантов коммуникации

Методы коммуникации в gRPC, которых нет в HTTP REST:

- Server Streaming RPC. Клиент отправляет один запрос серверу, а в результате получает поток ответов. Клиент в этом случае сам решает, читать ли до конца потока или до наступления иного события (таймаута по времени или наличия специфического поля в ответе)

- Client Streaming RPC. Клиент формирует поток сообщений и отправляет на сервер. После обработки сообщений, сервер возращает лишь один ответ клиенту.

- Bidirectional streaming RPC. Обе стороны (клиент и сервер) отправляют друг другу потоки сообщений. Потоки независимы, потому клиент и сервер могут обрабатывать сообщения паралелльно (как захотят).

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

Потоки и тестирование производительности
Из-за того, что потоки могут быть как на стороне клиента, так и на стороне сервера - усложняется не только функциональная часть тестирования.
Не все инструменты нагрузочного тестирования могут “из коробки” работать с потоками в gRPC. Например такие инструменты как k6.io или ghz работают только с единичными запросами и ответами в gRPC. Gatling и JMeter из коробки вообще не поддерживают gRPC - но хотя бы имеют плагины для такой функциональности.

Что такое консенсус в распределенных системах?

#distributedsystems #blockchain
Представим, что у нас есть система из четырех сервисов (S1, S2, S3 и S4). Так же есть пользователи (U1, U2, U3), которые делают запросы к сервисам.

Предположим, что есть два вида запросов: первый записывает данные в систему, а второй читает их.

Когда пользователь делает запрос, он не знает, на какой именно сервис попадет этот запрос. То же происходит и при чтении данных.

Вполне может случиться ситуация, когда пользователь U1 делает запрос на запись (set x = 10) на сервис S1, в это же время пользователь U2 делает запрос на запись (set x = 20) на сервис S3. Возникает вопрос - какое значение x получит пользователь U3 при отправке запроса на S4?

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

Ошибка при работе с Shadow DOM в Chrome 96+ (Selenium 3 и 4)

Утром открыл юай тесты и оказалось, что все они начали падать по неведомой причине.

Ошибка вот такая:
“java.lang.ClassCastException: class com.google.common.collect.Maps$TransformedEntriesMap cannot be cast to
class org.openqa.selenium.WebElement (com.google.common.collect.Maps$TransformedEntriesMap and
org.openqa.selenium.WebElement are in unnamed module of loader 'app')“

Оказалось, что Chrome поменял механизм работы с shadow DOM элементами и так просто закастить их в WebElement нельзя.

Вот тут - Titus описал как это можно побороть. Как раз попробую сегодня.