KaNoN

Ваш подход имеет место быть, так как он не противоречит здравому смыслу.

Понятное дело, это не единственный возможный вариант. Еще практикуются такие подходы:
1) Создаваемая сущность является уникальной для теста и при создании ее (в начале теста) проверяется существование данного объекта. Если объект уже был, то он перезаписывается. То есть создание/удаление делаются в одном месте

2) Операция удаления предварительно проверяет, а есть ли вообще что удалять. Если нет, то просто происходит выход. Где и как хранить значение - это уже дело десятое. Этот подход полезен тем, что мы оперируем полностью самодостаточными функциями, которые учитывают основные нюансы. В итоге тесты уже не содержат дополнительных проверок, условий, а представляют собой просто последовательность вызовов методов.

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

​Есть строки типа:
1. Гостиница Львов
2. Мини-гостиница Киев и область
3. База отдыха Буковель (Татаров, Яремча и другие города)...
Итого таких вариантов около 30.

Задача состоит в том чтобы оставит только название без типа. То есть после порезки должно остаться:
1. Львов
2. Киев и область
3. Буковель (Татаров, Яремча и другие города)

Пробовала такой код:

int index = str.indexOf(" ")+1;
        str = str.substring(index);

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

Скорее всего набор таких вот ключевых слов, которые надо обрезать, фиксирован. Как вариант, можно воспользоваться чем-то типа :

str = str.replaceAll("<here is the phrase to replace>" , "")

В итоге лишние слова будут просто убраны

шина с внешним миром общается через jms hornetq.
С помощью каких инструментов можно обеспечить тестирование? Нарыл пока только HermesJMS. Ну и soapUI, которым тот же HermesJMS можно подцепить.
Придумали ли чего то еще новое, какие еще есть инструменты? Или варианта только 2: писать код на Java или использовать HermesJMS?

Ну, можете глянуть еще Green Hat. Но как по мне для общения с JMS программного кода более чем достаточно. JMS клиент не требует больших усилий для написания, а сами автотесты по структуре просты и незамысловаты. Возможно, с проверками надо повозиться, но в остальном, все реализуемо. Более того, с другими инструментами вы будете делать то же самое и уж не факт, что инструменты позволят что-то ускорить. Хотя, тот же Soap UI мог бы быть полезен для "пристрелки", когда надо подготовить какой-то запрос и важна возможность быстрого перезапуска точечного запроса.

Они есть, только вот для веб-приложений полно решений подешевле, да и попроще. У Coded UI Testing сильная заточка под запись\воспроизведение, при этом генерируется много кода, который непросто подпилить. Даже если почитать Best Practices на MSDN, то слишком часто встречается именно recording. Может CUIT немного лучше в этом плане, но как по мне, пока о нем, как об оформившемся решении говорить рано.

З.Ы.: Для возможностей интеграции с TFS достаточно использовать MSTest.

А если не смотреть на цену, а смотреть в функционал и "БОЛЬШИЕ" возможности, в основном в интеграции баг трекинг системой с тестовой средой.

Это не такая уж большая возможность, к тому же, как я уже упоминал, такую интеграцию уже обеспечивает MS Test.

Да подпилить не просто,но если есть желание и время,думаю можно освоить,

А нужно ли? Если то же самое можно сделать другими средствами, которые подпиливать не надо.

за рубежом достаточное количество тестировщиков работают с Visual Studio,можно посмотреть на stackoverflow...

Visual Studio это вовсе не значит Coded UI. Тут не надо путать. И ее используют не только для Coded UI тестов. Есть много других направленийю Например, те же веб-сервисы вполне удобно покрывать юнит-тестами. Для этого никакого дополнительного тула не надо.

В IE тесты записываются и прогоняются идеально, а вот с другими браузерами печально,если тестовый пример поиск слова cheeze в гугле работает во всех браузерах, а уже более сложное никак(Ждем апдейтов CUITe фраймворка возможно он исправит, а то там почти год не было изменений...хотя последний update 1 для visual studio 2012 мало что внес полезного для тестирования( />

Жто еще один повод подумать о каком-то другом решении, благо для веба их немало, в том числе и на базе C#

Неужели нету тестеров дотнетчиков?) печально?)

Они есть, только вот для веб-приложений полно решений подешевле, да и попроще. У Coded UI Testing сильная заточка под запись\воспроизведение, при этом генерируется много кода, который непросто подпилить. Даже если почитать Best Practices на MSDN, то слишком часто встречается именно recording. Может CUIT немного лучше в этом плане, но как по мне, пока о нем, как об оформившемся решении говорить рано.

З.Ы.: Для возможностей интеграции с TFS достаточно использовать MSTest.