Свободу тестам

Современный мир ПО очень черно-бело разделён на два лагеря: либо ты opensource-приложение, либо закрытое проприетарное. Нет, есть, конечно, и разные лицензии в открытых проектах и какие-то подвижки закрытых продуктов выкладывать в опенсорс свои части (привет, Google, Facebook, Microsoft). Но всё это не меняет сути дела в принципе — если ты берёшь открытый продукт, то видишь всё, что у него внутри, можешь это оценить и решить, стоит связываться или нет. Если ты хочешь приобрести закрытое ПО, то всё, что остаётся — верить заливающимся соловьями продажникам фирмы-производителя, как у них там всё внутри классно, надёжно, быстро и современно. Ну, вы наверняка были на какой-нибудь такой конференции или презентации, где выходил человек в костюме и час втирал о том, как же всё стало лучше в версии 18.1.1 их продукта и почему его нужно покупать прямо сейчас. Ещё часто можно недельку погонять ограниченный trial-режим, что даст ответ ровно на 1 вопрос: «как работает ограниченный trial-режим в течение недели?». Покупатель всегда остаётся один-на-один с решением «взять и рискнуть» или «не связываться». Объективных данных для принятия решения мало. При этом их, казалось бы, больше и не станет — производитель закрытого продукта не выложит исходники, поскольку именно они составляют коммерческую ценность.

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

1. Производитель показывает, что тесты у него есть. Не то чтобы это автоматом говорило, что продукт хороший, но вот если тестов совсем нет — это уже с полной гарантией говорит, что продукт плохой. Т.е. от оценки «а чёрт его знает, как его там кто тестировал» мы переходим к оценке «так, что-то люди вроде бы пытались тестировать».

2. Производитель не открывает исходный код своего продукта. Да, тесты могут кое-что рассказать об устройстве отдельных модулей и их взаимодействии, но давайте смотреть правде в глаза — дебаггер и дизассемблер раскажут не меньше.

3. Потенциальный покупатель может оценить качество кода тестов. Да, это не код самого продукта, но пишутся тесты обычно теми же людьми, в том же стиле, с тем же отношением к стилю, качеству кода, именованию сущностей, с той же тщательностью. Если у покупателя нет навыков оценить качество кода — можно нанять стороннего консультанта для аудита.

4. Тесты, возможно, удастся даже запустить. Это, конечно, уже потребует от производителя некоторой дополнительной работы — выноса кода в отдельные изолированные компоненты, создание дополнительных моков. Но, скажите мне, что же тут плохого? Данный подход стимулирует писать хороший код продукта, а значит он идёт на пользу всем. Более того, если тесты можно запустить на реальном продукте — их можно использовать для диагностики ошибок, переписки с техподдержкой.

5. Тесты, возможно, удастся расширить для своих нужд. К примеру, есть тест, который проверяет сохранение 1000 документов в базу данных. А нам нужно гарантировать успешное сохранение 100 000 документов. Если задать вопрос производителю ПО, то вы услышите или «да, конечно всё будет работать!» (если попадёте на продажника) или «не знаю, не проверяли на таких количествах» (если попадёте на инженера). Оба ответа бесполезны. Если же у вас будет готовый тест для 1000 документов, вы легко измените его размерность и, запустив, узнаете ответ на свой вопрос.

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

7. Производитель сможет наконец в лицензионном соглашении вместо позорных формулировок «ничего никому совершенно не гарантируется» писать хотя бы «гарантируется прохождение прилагаемых к продукту тестов». Это, согласитесь, значительно лучше, чем коты в мешках, которых нам предлагают сегодня.

8. Острота столкновений opensource и закрытого ПО станет менее кровавой. От «частично открытого» ПО у свидетель секты GNU глаза наливаться кровью будут уже чуть меньше. Тут, конечно, многое зависит от толкования и пиара, но всё же шаг навстречу это лучше, чем нынешние прямые конфликты.

9. Будет, о чём поговорить с пользователями. Многие команды маркетинга и пиара бьются над получением от пользователей адекватного фидбека, втягивание их в разговор, попытки продать дополнительные модули и техподдержку. К сожалению, начинать такие разговоры часто приходится с голого фундамента, беседа не клеится. И совершенно другое дело, когда разговор начинается уже предметно — с заваленного теста, с запроса на добавление фичи, с вопроса о том, почему вот здесь и здесь в тест передаются такие параметры, а не такие, «а где вообще проверяется вот этот случай?» и т.д… Когда разговор технических специалистов приведёт к локализации проблемы или необходимости разработки новой фичи — это будет уже хороший фундамент для обсуждения дальнейшей сделки.

Очень интересно ваше мнение по поводу возможности открытия кода тестов для проприетарного ПО.

ссылка на оригинал статьи https://habrahabr.ru/post/281785/