Разработка с уверенностью без реальной среды разработки

12

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

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

Как это делают те, кто эффективно справляется с подобными ситуациями?

testing development-process

— Джейсон Светт
источник

1

Виртуализация, «похожая» на среду и т. Д. По сути, попытайтесь воспроизвести то, что вы можете, в меньшем масштабе, чтобы охватить, по крайней мере, большинство «движущихся частей» системы.

— Одд

6

Вы должны полагаться на правильность API корпоративной системы и проводить множество интеграционных тестов, возможно, с некоторыми тестовыми аккаунтами.

— Роберт Харви

@RobertHarvey здесь мертв. Кто-то должен разъяснить это в ответе, но это именно то, что вам нужно. В отсутствие среды для ручного тестирования системы все, что вы можете сделать, это автоматически протестировать код.

— Джимми Хоффа

1

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

— Джейсон Светт

9

Это происходит все время в реальном мире. Я знаю парня, который пишет приложения, которые контролируют гигантские сельскохозяйственные теплицы - вентиляцию, отопление, контроль влажности, вы называете это. У него нет «тестовой теплицы», но у него есть программа-симулятор, предоставленная компанией, которая создает реальные аппаратные системы. Если код корректно работает с симулятором, предполагается, что он корректно работает с реальным оборудованием. В редких случаях симулятор оказывается неправильным, но это проблема компании-производителя теплиц, потому что он не симулирует правильно.

— Росс Паттерсон
источник

ОП, похоже, не имеет гарантии на «симулятор». Кроме того, в вашем случае, работодатель вашего коллеги, вероятно, может запросить компенсацию в случае сбоя симулятора. Что может сделать ОП в подобной ситуации? Беспокоить страховую компанию?

— К.Стефф

4

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

— Mattnz

3

Это ситуации, в которых первыми были документация по API, документы по управлению интерфейсом и эмуляторы. В компании, в которой я работал ранее, это действительно происходило, это часто происходило в рамках проекта на определенных этапах интеграции, когда один сегмент был готов, но другие были позади, над какой-то другой функцией работали, или по какой-то другой причине они не смогли развернуть последняя версия своего сегмента для нашей тестовой системы. Итак, да, у нас действительно была точная копия нашей производственной среды, на которой мы тестировали; однако на практике все сегменты никогда не были готовы по графику, но интерфейсы были согласованы и заблокированы до начала разработки, и были созданы эмуляторы, которые могли бы по большей части имитировать поведение других сегментов.

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

— Фред Томсен
источник

1

Я нахожусь в таких ситуациях все время.

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

Вы также можете сделать гибрид. Попробуйте воспроизвести части, которые вы можете довольно легко выполнить, а затем «подключиться» к реальным системам (если это возможно в вашей ситуации). Я сделал это с некоторым успехом - в некоторых случаях, когда моя логика и серверное программное обеспечение работали локально, но у меня все еще были соединения с реальной системой ERP для проверки вызовов и т. Д. Не идеально, но это редко случается.

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

На предприятиях рекомендуется создавать реплики (или, возможно, более одной) продукции в момент настройки производственной среды. В этот момент дополнительные расходы не будут такими большими.

— Петтер Нордландер
источник

1

Наша система работает с рядом крупных внешних систем. Мы объединяем следующие подходы при их тестировании, если у нас нет полной сквозной настройки:

Запись-воспроизведение реальных данных. Записывать реальные данные (запросы / ответы от реальных внешних систем), параметризировать их при необходимости и воспроизводить
Построить или купить симулятор, который действует как внешняя система
DSL для генерации тестовых данных. Для систем, управляемых данными, напишите высокоуровневый DSL для генерации тестовых данных.

— dzieciou
источник