Программист с 45-тилетним стажем поделился советами перед уходом на пенсию. В основном все советы не про технологии, а про команды и отношения. И крутятся вокруг «делай как проще, чтобы другим было понятнее» и «заботься о коллегах и команде, плохие команды хороший продукт не сделают». Но среди них только один технический: пишите автотесты, чтобы команда могла уверенно двигаться вперед.

via

Среди систем непрерывной интеграции высокая конкуренция, они борются за пользователя всеми возможными способами: поддержкой редких ОС (типа FreeBSD), какими-то фишками или хорошим "железом". Но несмотря на конкуренцию есть проблема, с которой никто не спешит разбираться. Это vendor lock-in на конфигурацию определённой CI системы. То есть если вы используете Travis CI (не используйте их) и решили переехать на другой сервис или self-hosted систему, то вам надо будет переписать .travis.yml на другом декларативном языке, то есть буквально воссоздать пайплайн с нуля. В некоторых случаях это переписывание с одного YAML на другой YAML. Можно конечно вынести все проектно-зависимые вещи в скрипты (например под каждую операцию: run.sh, build.sh, test.sh, bootstrap.sh) и в конфиге CI вызывать их или все это реализовать в Make/CMake и в конфиге вызывать таргеами, типа make build; make test, но по моему опыта так мало кто делает и к тому же окружение на всех CI немного разное и на Travis CI нужно установить компилятор, а на другом нет и т.д. Все равно вы потратите ощутимое время на переезд с одного CI на другой.

Я уже писал про сервис Cirrus CI, я им пользуюсь потому что там есть поддержка FreeBSD, которая мало где есть, и мне понравилось как они развязали руки своим пользователям. Те, кто использует в своем проекте Cirrus CI, могут запускать пайплайн отдельно от сервиса с помощью их утилиты. Это позволяет при наличии одного конфига запускать локально, на другом CI сервисе или где-то ещё. Круто же!

via

​​Амазон анонсировала появление нового сервиса для chaos инжиниринга (напомню, это "проведение экспериментов в распределенных системах с целью укрепления уверенности в способности системы противостоять турбулентным условиям в эксплуатационной среде". см основные принципы хаос инженерии). По сути это AWS Chaos Runner, который реализует разного рода сбои, интегрированный в экосистему AWS (см. иллюстрацию). Амазон не первыми делают такой сервис, уже давно существует Gremlin, который предоставляет сбои как сервис. Тут, как мне кажется, интересно другое - Амазон с этим продуктом выходит на рынок продуктов для тестирования ПО. С таким же успехом они могут сделать сервис для тестирования Web UI.

https://aws.amazon.com/fis/

​​В свежих сборках Chrome появилась возможность записывать сценарии действий пользователя в скрипты на Javasript. То есть открываете нужную страницу в бразере, в DevTools включаете запись действий и делаете что-то на странице обычным образом. По мере выполнения действий браузер генерирует Javascript код, описывающий через API Puppeteer все ваши действия. После этого запись можно остановить, и сохранить полученный код.

https://developers.google.com/web/updates/2021/01/devtools#record

P.S. За конкуренцией в области сокращения расходов на автоматизацию тестирования WebUI становится интересно следить. Помимо встроенной в Chrome поддержки записи сценариев ещё есть: Selenium IDE, который не так давно реанимировали после длительного анабиоза, есть коммерческие сервисы, призванные снизить порог вхождения в автоматизацию тестирования Web UI (например малоизвестные у нас стартапы testRigor или Virtuoso QA) и у них тоже есть расширения для записи сценариев. Про Cucumber и прочие BDD-like решения я даже и не говорю.

JetBrains каждый год делает опрос разработчиков, чтобы узнать состояние индустрии разработки ПО. Потом они публикуют данные по результатам опроса.
За предыдущие года результаты можно найти здесь. Результатами я неоднократно сам пользовался.
Недавно стартовал опрос за 2021 год и я предлагаю вам тоже в нем поучаствовать.

https://surveys.jetbrains.com/s3/a1-developer-ecosystem-survey-2021

Захватывающая история о неработающей синхронизации в rsync, причиной которой был баг 24-летней (!) давности в реализации протокола TCP Linux ядра. Буквально через несколько часов после появления письма с описанием проблемы в рассылке Neal Cardwell подготовил патч с исправлением (фикс из двух строк). Знаю Neal Cardwell как автора packetdrill - утилиты для функционального тестирования TCP, IP протоколов. С её помощью тесткейсы для тестирования можно описывать на DSL в декларативном стиле и они выглядят короче и нагляднее, чем такой же тексткейс, но на Си.

// Create a listening TCP socket.
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0

// Establish a new connection.
+0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 win 29200 <mss
 1460,nop,nop,sackOK,nop,wscale 6>
+.1 < . 1:1(0) ack 1 win 257
+0 accept(3, ..., ...) = 4

// sequence number out of window!
+.010 < R. 29202:29202(0) ack 1 win 257

// verify that the connection is OK
+.010 write(4, ..., 1000) = 1000
+0 > P. 1:1001(1000) ack 1

https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/

Почему вы должны писать тесты? Версия ответа от Dave Cheney:

- Even if you don't, someone will test your software
- The majority of testing should be performed by development teams
- Manual testing should not be the majority of your testing because manual testing is O(n)
- Tests are the critical component that ensure you can always ship your master branch
- Tests lock in behavior
- Tests give you confidence to change someone else's code

За последнее время в Hypothesis (библиотека на Python для property-based тестирования) появились новые фишки, о которых я расскажу в нескольких следующих постах.

Гугл недавно опубликовал под свободной лицензией исходный код Аtheris. Это фаззер для кода на Python, он использует LibFuzzer и, как следствие, генерирует такие входные данные, которые максимимизируют покрытие кода, то есть это фаззер с обратной связью. Как пишут в анонсе, в 2013 году гуглеры организовались и начали писать фаззеры для внутренних проектов кода. В рамках этой активности и был создан Аtheris. Hypothesis позволяет использовать внешние фаззеры для генерирования тесткейсов (например на базе AFL - python-afl), и теперь есть интеграция с Atheris. В инфраструктуре oss-fuzz, в которой Гугл фаззит код открытых проектов, теперь появилась поддержка проектов на Python и туда уже добавили два модуля (ujson и urllib3), которые теперь регулярно тестируются с помощью связки Hypothesis и atheris. Все это говорит о том, что Hypothesis умеет генерировать тесты не только с использованием свойств, но и абсолютно случайными данными. Кстати нативная поддержка coverage-guided генератора была в самом Hypothesis, но её удалили в основном из-за проблем с производительностью в 2018 году (см. тикет).

Пример кода для тестирования с использованием Atheris и Hypothesis:

@given(obj=JSON_OBJECTS, kwargs=st.fixed_dictionaries(UJSON_ENCODE_KWARGS))
def test_ujson_roundtrip(obj, kwargs):
    """Check that all JSON objects round-trip regardless of other options."""
    assert obj == ujson.decode(ujson.encode(obj, **kwargs))

if __name__ == "__main__":
    atheris.Setup(sys.argv, test_ujson_roundtrip.hypothesis.fuzz_one_input)
    atheris.Fuzz()

#непишитетесты, а лучше генерируйте их

Платформа для фаззинга OSS Fuzz от Гугла стала ближе к миру энтерпрайза вместе с поддержкой кода на Java. В феврале компания Code Intelligence опубликовала с открытой лицензией код своего фаззера Jazzer. Помимо языка Java Jazzer ещё поддерживает Scala, Kotlin и Clojure. А сегодня Гугл анонсировал поддержку Java проектов в OSS Fuzz с помощью Jazzer.

Чтобы два раза не вставать. OSS Fuzz это только одна платформа для фаззинга и только для проектов с открытым исходным кодом. Для проприетарных проектов есть ClusterFuzz, на базе которого работает OSS Fuzz, и платформы от других компаний: Microsoft OneFuzz, сервис уже упомянутой компании Code Intelligence, FuzzBuzz.

https://google.github.io/oss-fuzz/getting-started/new-project-guide/jvm-lang/