TatyanaV

css:

[id*='ContentPlaceHolder_Workplace_ctl']

Можно еще добавить [id*='_div_main'], но это уже излишне. Если конечно у вас на странице нет ещё кучи элементов, в id у которых есть указанная строка.

п.с.: в той ссылке, которую вам дали - это есть.

1. Вы не написали, что (точнее как) не срабатывает? :) Ошибки бывают разные - элемент не найден, либо найден, но недоступен и т.п.

2. Насколько я понимаю, #l_msg - это элемент списка, а By.linkText("Мои сообщения") - это span, который наоборот: лежит внутри ссылки (тоже может быть недоступен для Селениума).

Попробуйте кликнуть не по ним, а непосредственно по ссылке = driver.findElement(By.cssSelector("#l_msg a")).

Сначала дожидаетесь обновления страницы.

Потом:

Если нужно именно с условием if:

ArrayList<WebElement> elementsFound = getWebDriver().findElements(<тут уникальный локатор, по которому можно найти элемент только на этой странице>);
if (elementsFound.size() > 0) {
   <тут клик по кнопке>
}

Либо

try {
    <клик по кнопке, если знаете для нее уникальный идентификатор, по которому можно найти только эту кнопку>
} catch (NoSuchElementException ignore) {}

Может кто-то со мной не согласится, но после тестового сценария должен быть 1 ожидаемый результат.

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

Все зависит от того, что именно Вы считаете "логикой" теста.

К примеру, у меня приложение по заполнению анкет (каких не важно, но информации в них много).

Для меня "логика" теста - метод подготовки данных по нужным мне условиям + метод заполнения анкеты + проверка результата.

В этом случае - никакого логики не будет. Все линейно.

Но ВНУТРИ метода подготовки данных и метода заполнения анкеты - и условия, и логика полноты и порядка заполнения в зависимости от условий, и ОТДЕЛЬНО логика работы с элементами (хелперы отдельно, описания страниц отдельно).

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

Могу сказать, что тесты у меня успешно запускаются на разных "площадках", с разными исходными данными/версиями и т.п., без необходимости что-то подстраивать в тестах. Они сами подстраиваются, подбирают нужные данные и знают, что и как выполнять.

======================

По теме - попробуйте так (ну или любой из предыдущих вариантов, с заменой сравнения по "!=" на !equals):

    public void controlStateForTesting() throws InterruptedException {
        ArrayList<WebElement> tabs = (ArrayList) driver.findElements(By.xpath("//div[@id='tabbed']//span"));
        if (tabs.size() > 0 && !tabs.get(0).getText().equals("New plan"))
        {
            deleteActionPlan();
        }
    }

Кстати, по коду у вас два таба: <li class="tab0 selected" > и <li class="tab1 last" >.

Если вам нужно проверять именно первый - зачем ищите 'tab1'?

Вы же делали уже такую тему?

Возможно дело в том, как именно вы запускаете свои тесты. (см. сообщение от Vad1m198)

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

Есть еще такой момент.

Когда запускается сразу набор тестов идущих друг за другом - неожидаемый алерт в одном из тестов (который вы никак не обработали) - можно помешать дальнейшему выполнению других тестов. Эти "другие" тесты = и будут отмечены как "не запускавшиеся".

Попробуйте где-нибудь в базовом классе, от которого у вас наследуются тестовые классы, добавить доп.проверку:

    @AfterMethod
    public void testEnd(ITestResult result) {
        checkAlert();
    }
	    
    public void checkAlert() {
        try {
            app.getDriver().switchTo().alert().accept();
            log.warn("Alert has been found and accepted.");
        } catch (NoAlertPresentException e) {}
    }

После каждого тест-метода будет вызываться проверка на наличие алерта. Если он вдруг найден - он будет подтверждаться. Если считаете, что что такой алерт у вас = ошибка, можно вместо подтверждения добавить "throw new Exception(<текст ваш>)".

Это не избавит от необходимости выяснить, почему алерт появился там, где вы его не ждете (может это баг того ПО, которое вы тестируете? или просто тест не доделан), но хотя бы не будет мешать дальнейшему выполнению остальных тестов.