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

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

Всем привет! Мы хотим продолжить серию постов на тему “где используются эти ваши странные языки программирования”. В прошлый раз мы рассказали про Лисп, а сегодня продолжим разговор про функциональные языки и обратим внимание на Haskell.  Он является основным языком разработки в Typeable и, конечно, мы не смогли пройти мимо такой темы.

Haskell — чистый функциональный язык программирования общего назначения. Среди его отличительных особенностей можно выделить строгую статическую типизацию, ленивые вычисления, алгебраические типы данных и серьёзную теоретическую основу. Это относительно молодой язык, он появился в 1990 году, но уже оказал значительное влияние на другие языки и на теорию языков программирования в целом.

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

Введение

Лисп — второй по старшинству из ныне живых высокоуровневых языков программирования (после Fortran) и первый функциональный язык. Он был разработан в 1958 году и сильно изменился с тех пор, породив множество диалектов и оказав значительное влияние на развитие других языков. На данный момент наиболее известные диалекты: Common Lisp, Scheme, Racket и Clojure.

Слева: Лисп-машина в музее MIT.
Справа: Лисп-машина Symbolics 3640, фото Michael L. Umbricht и Carl R. Friend (Retro-Computing Society of RI)

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

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

Мы в Typeable любим и применяем функциональное программирование, а влияние Лиспа на функциональные языки всё ещё сильно, поэтому нам стало интересно разобраться в этом вопросе.

Как Unicode уничтожает большинство ваших предположений о том, как на самом деле работают строки

Когда речь идет о написании чего-то простого, мы, программисты, обычно действуем интуитивно. В случае с простыми вещами мы полагаемся на четкий набор предположений вместо конкретных знаний о том, как эти вещи работают. Например, мы предполагаем, что если b = a + 1, то b больше a, или что если мы применим функцию malloc для какого-то буфера, то получим необходимое количество памяти для записи. Мы не заглядываем в документацию всякий раз, когда имеем дело с мелочами.

Мы делаем так, потому что тотальная проверка замедлит работу. Однако если бы мы все-таки провели проверку, мы бы обнаружили, что обычно ошибаемся в своих предположениях. Существует арифметическое переполнение, в результате которого a + 1 может быть значительно меньше, чем a. Иногда malloc дает нам null вместо буфера и мы оказываемся в пролете.

Нам обычно приходится обжечься на таких вещах, чтобы хотя бы немного изменить свои предположения. И даже тогда мы обычно исправляем их весьма условно.
Столкнувшись с досадной ошибкой переполнения, мы можем скорректировать свое предположение о целых числах в виде «a + 1 больше a, если отсутствует вероятность, при которой a представляет собой очень большое число». И мы действуем исходя из этого, вместо того, чтобы обдумать четкие правила, по которым работает переполнение.

Уточненные предположения – это опыт. Чаще всего они позволяют нам работать быстрее и правильнее. Однако мы можем вообще переместить некоторые вещи, например, правильную обработку malloc, из нашей внутренней категории «простые вещи» во внутреннюю категорию «сложные вещи». И тогда мы действительно можем пойти и уточнить, как они работают.

Автор статьи: klntsky

Что такое Property-Based Testing?

Property-based testing (PBT) — подход к тестированию ПО, подразумевающий автоматическую проверку свойств функций (предикатов), специфицируемых программистом-тестировщиком. Для проверки, т.е. поиска контрпримеров, используются автоматически сгенерированные входные данные. PBT позвляет разработчикам значительно увеличить тестовое покрытие и эффективно расходовать своё время, не придумывая входные данные для тестов самостоятельно. В общем случае данные, генерируемые во время property-based тестирования, ничем не ограничены, поэтому проверка может быть произведена на тех значениях, про которые разработчик мог забыть или для которых не счёл нужным написать юнит-тесты (действительно, не перебирать же все значения входных параметров вручную).

PBT-подход был популяризован библиотекой QuickCheck, написанной на Haskell, и в этой статье будет показано, как пользоваться этим инструментом эффективно.

Команда Typeable понимает ценность безопасности. Мы любим Haskell, но стоит ли его выбирать, если ваша цель – создание защищенного программного обеспечения? Хотелось бы сказать «да», но как и для большинства эмпирических вопросов о разработке ПО, здесь просто нет объективного доказательства, подтверждающего, что Haskell – или ещё какой-нибудь язык программирования – обеспечивает большую безопасность, чем любой другой. Нельзя сказать, что выбор языка в Typeable не имеет значения для безопасности, но какое именно значение он имеет, еще нужно подумать.

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

Введение

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

Данная статья описывает небольшой пример того, как использование языка моделирования Alloy может помочь при разработке программного обеспечения.

О качестве программного обеспечения и инструментарии

В Typeable мы придаем огромное значение качеству программного обеспечения и прикладываем все усилия, чтобы обеспечить это качество. В настоящее время мы искореняем ошибки следующими способами:

1. Анализ и создание спецификаций
2. Устранение простых ошибок с использованием системы типов Haskell
3. Стандартные юнит-тесты и интеграционные тесты
4. Непрерывная интеграция
5. Обязательные ревью кода
6. Тестирование на стендах, проводимое QA инженерами
   (мы используем Octopod для оптимизации процесса разработки и QA)
7. Тестирование в pre-production среде
8. Ведение логов и контроль ошибок на этапе эксплуатации

Такое большое число шагов обеспечивает высокое качество кода, но при этом сказывается на затратах. Для выполнения этих шагов нужно и время, и труд.

Введение

Как узнать, что человек понял, что такое монады? Он сам вам об этом расскажет в первые 5 минут общения и обязательно попробует объяснить. А ещё напишет об этом текст и по возможности где-нибудь его опубликует, чтобы все остальные тоже поняли, что такое монады.

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

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

Моё изложение во многом основывается на книге Бартоша Милевски "Теория категорий для программистов", которая создавалась как серия блогпостов, доступна в PDF, а недавно вышла в бумаге.

Примеры приводятся на Haskell, предполагается, что читатель знаком с синтаксисом и основными понятиями языка. В упомянутой книге есть примеры и на С++, можете сравнить чистоту и понятность кода.

Мотивация

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

Мне не хватало хорошего примера, где бы окупались усилия, потраченные на освоение "матчасти". Для меня одним из самых удачных таких примеров оказались парсеры. Теперь я довольно часто рассказываю про них, когда у меня спрашивают, для каких распространённых задач можно красиво использовать Haskell.

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

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