Сообщений в теме: 44

[Little_CJIOH]

плохая идея. половина результата работы находится в очередях и таблицах Оракла. В ГУИ у вас настройка бизнес-логики и ручные корректировки. все остальное запускается тасками в оракле.

[Vla8islav]

В чем проблема работать с Ораклом? Если большая часть тестируемой логики "под капотом", то имеет смысл в первую очередь поинтересоваться у вашего автоматизатора, на чем ему будет комфортнее всего писать, и потом плясать от этого.

 

Единственно что приходит в голову - что бы вы не выбрали, очень советую чтобы IDE имел хорошую поддержку работы с БД. Отдельно PL/SQL, отдельно IDE для написания автотестов - это боль, знаю не по наслышке.

[Little_CJIOH]

Автоматизатор - аутсорсер. Сегодня он есть, а завтра нет. Поэтому разработка автотестов будет идти с использованием принятых в компании технологий. Даже я, постоянный сотрудник, не могу и не буду писать тесты на поддержку которых нужно будет искать специального человека. Буду плеваться, но писать на java.

А большая часть логики даже не под капотом, а в настройке и конфигурации системы.

 

Какие еще будут предложения?

[Vla8islav]

Буду плеваться, но писать на java.

Успехов. Я про протрактор не зря написал, попреваться с ангуларом вам малость придется.

[leftCh]

Автоматизация тестирования - must have, это политика партии.

 

Прям завидую 

 

Я так понимаю основная проблема в асинхронности этого "добра" и зависимости от инфраструктуры? Если так, то вот что говорят гуру на этот случай

 

Цитата: 

Часто возникает необходимость тестировать программное обеспечение, которое тесно

связано с некоторой инфраструктурой. В качестве примеров можно назвать визуальные

компоненты (например, графические элементы, диалоговые окна) и встраиваемые тран

закционные модули. Тестирование таких объектов затруднено, так как создание всех

объектов, с которыми взаимодействует тестируемая система, может оказаться слишком

дорогим или вообще невозможным. В других случаях объекты могут оказаться сложными

в тестировании из за асинхронного взаимодействия; в качестве примеров можно назвать

активные объекты (потоки, процессы, Web серверы) и пользовательские интерфейсы.

Асинхронность таких объектов вносит долю неуверенности, требования к межпроцесс

ной конфигурации и необходимость добавления задержек внутри тестов. Иногда из за

всех этих проблем разработчики просто отказываются тестировать подобный код. Ре

зультатом становятя ошибки в продукте (Production Bugs, с. 303), вызванные нетестиро

ванным кодом (Untested Code) и нетестированными требованиями (Untested Requirement).

Минимальный объект (Humble Object) позволяет протестировать логику сложно созда

ваемых объектов без значительных затрат.

 

Как это работает

Вся логика сложного в тестировании компонента выносится в компонент, поддающий

ся проверке синхронными тестами (synchronous test). В таком компоненте реализуется слу

жебный интерфейс, состоящий из методов, которые обеспечивают доступ к логике нетес

тируемого компонента. Единственным отличием является доступность этих методов через

синхронные вызовы. В результате компонент минимального объекта (Humble Object) высту

пает в роли тонкого слоя адаптера с минимальным объемом кода. При каждом вызове ми

нимального объекта (Humble Object) со стороны инфраструктуры объект делегирует запро

шенные операции тестируемому компоненту. Если тестируемый компонент нуждается

в информации из контекста, минимальный объект (Humble Object) извлекает эту информа

цию и передает тестируемому компоненту. Код минимального объекта (Humble Object)

обычно настолько простой, что даже не требует создания отдельных тестов.

 

Когда это использовать

Минимальный объект (Humble Object) можно и нужно вводить при наличии нетриви

альной логики в компоненте, экземпляр которого сложно создать из за зависимости от

инфраструктуры или доступный только асинхронно. Существует множество причин

сложности тестирования объектов. Следовательно есть множество вариантов разрыва

этих зависимостей. Следующие варианты являются самыми распространенными приме

рами минимальных объектов (Humble Object), но не стоит удивляться, что время от време

ни придется придумывать собственный вариант.

 

Продолжение в книге, название которой в посте выше.