О статусе релиза.

- What is the release status?
- "We have enough fails for now"(c).

Как оно, начинать.

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

И снова о локаторах.

Отличный локатор элемента.

О бардаке с управлением и рулением.

"Никакого бардака с рулением нет, у нас спонтанно-динамическая стабилизация по всем каналам управления с элементами роевой самоорганизации."(а).

TestNG, skipped tests and "why" related information.

 As usually there are passed, failed and skipped tests. TestNG map skip tests due to failures in
precondition steps (i.e. somewhere inside all those @BeforeSuite/Group/Method routines). In such a case there is no quick-human-readable
explanation why a test was skipped. That is a pity, so what about the following:
1. Go to TestListenerAdapter#onTestSkipped(ITestResult result);
2. Check Throwable of that ITestResult;
3. If null then get skipped configurations - result.getTestContext().getSkippedConfigurations();
4. I haven't found a straight way to link skipped configuration and skipped test, but one could try to do that via TestContext/TestClass:
check whether skippedConfig.getTestClass().equals(result.getTestClass()))
5. If there is skipped config caused the test to be skipped then use result.setThrowable() to transfer throwable to ITestResult;
6. No guarantees but seems to work.

TestNG, пропущенные тесты и информация о причинах.

 Как общенеизвестно тесты после прогона бывают прошедшие, упавшие и пропущенные.
ТестНГ "пропускает" тесты в том числе и потому что что-то упало на этапе подготовки -
если где-то в глубинах @BeforeSuite/Group/Method что-то завалилось, то всё, гонять зависимые тесты уже нет смысла, сворачиваемся и идём обедать.
К сожалению в этом случае тесты хоть и помечаются "пропущенными", но без особого объяснения причин(лишь бодрое ничего приветствует любопытствующих), мол смотрите логи, может повезёт.

А хочется же подробностей и вот что придумалось:
1. TestListenerAdapter#onTestSkipped(ITestResult result);
2. Проверить Throwable в ITestResult;
3. Если налловое, то вытащить пропущенные/порушенные конфигурации через result.getTestContext().getSkippedConfigurations();
4. Способа связать упавший конфиг с конкретным тестом не нашёл, но можно сделать это через тестовый класс:
skippedConfig.getTestClass().equals(result.getTestClass()))
5. Если удалось связать, то через result.setThrowable() "перенести" исключения из конфигов в ITestResult
6. На практике даже вроде работает.

Программное обновление статуса прогона тестов ТестЛинк.

 На проекте завёлся TestLink - жизнь стала насыщенее и встал вопрос хранения результатов прогона регрессии в том числе и в нём. Сохранять вручную конечно же не вариант, а посему нужно программное решение. И тут началось... .

 Задача - по результатам прогона тестов обновлять соответствующие сущности в ТестЛинке (создавать, удалять объекты не нужно, просто сохранять результаты прогона тестов на конкретной сборке.)
 Идея - использовать некий клиент для тестлинковского ПИП чтобы после прогона теста/тестов загружать результаты.
 Дробности решения:
1. яндексирование выявило лишь одну более-менее свежую реализацию - http://kinow.github.io/testlink-java-api/index.html
2. ПИП этот разрабатывал какой-то маньяк-ветеран. Методы, отсвечивающие стройными рядами входных параметров, прямо таки напомнили "святые 90-е", Win32API и Паскаль.
3. чтобы вызовы заработали нужно не только заиметь/сгенерировать ключ (http://forum.testlink.org/viewtopic.php?f=10&t=2858), но и кое-что включить в настройках сервера - https://github.com/parthibann/Python-TestLink-Runner/wiki/Enabling-Test-Automation-in-Testlink
4. если неизвестно что именно передавать в методы(см. выше), то можно смело пробовать налловые значения, часто помогает.
5. всё очень медленно.
6. "внешние" идентификаторы тестлинковских кейсов можно хранить в аллюровских @TestCaseId (связь тест<->тест_кейс). Вытащить данные из аннотаций достаточно легко. Под "внешними" имеется в виду идентификаторы вида ТА-1234, где ТА это аббревиатура названия проекта в ТестЛинке, а 1234 это порядковый номер кейса.
7. вполне можно делать всё в TestListenerAdapter#onFinish() (речь о TestNG):

URL testLinkURL = new URL(testLinkHost + "/lib/api/xmlrpc.php");
testLinkApi = new TestLinkAPI(testLinkURL, devKey);

report(testLinkApi, testPlan, testBuild, ExecutionStatus.NOT_RUN, 
        testContext.getSkippedTests().getAllMethods()); 

report(testLinkApi, testPlan, testBuild, ExecutionStatus.PASSED, 
        testContext.getPassedTests().getAllMethods()); 

report(testLinkApi, testPlan, testBuild, ExecutionStatus.FAILED, 
        testContext.getFailedTests().getAllMethods());

... 

private void reportResult(TestLinkAPI testLinkApi, TestPlan testPlan, 
                          Build testBuild, ExecutionStatus status, 
                          Collection testNgMethods) 

  for (ITestNGMethod testMethod : testNgMethods) {
    String testCaseId = getExternalIdFromAnnotations(testMethod, testMethod.getMethodName());
    for (String extId : testCaseIds) {                
      try {                    // 'null' - to return the latest version of test case                    
        TestCase testLinkCase = testLinkApi.getTestCaseByExternalId(extId, null);                    
        testLinkApi.reportTCResult(testLinkCase.getId(), null, testPlan.getId(),
                                status, testBuild.getId(), null, 
                                "A note on test case execution,", 
                                null, null, null, null, null, null);
        } catch (TestLinkAPIException e) { 
                           //Do something... .
         }
    }
  } 
 }
}

О чайниках.

"Офисные хомячки"(тм) делятся на тех кто доливает чайник после использования и на тех кто нет.

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

Авто-тесты падали, падают и будут падать. Это данность данная нам в болевых ощущениях, яркостью которых конечно же хочется управлять - перезапуская упавшие тесты например. TestNG поддерживает это желание и предоставляет набор стандартных средств для программного перезапуска. Как, что и где хорошо написано вот в этой статье (и в этой), однако "есть нюансы". А именно, каждый прогон теста попадает в отчёт, т.е. перезапущенные тесты  показываются и в "пропущенных" и в "прошедших"/"упавших" - тест 1 раз упал, 3 раза был перезапущен (два раза упал, на последнем прогоне внезапно "позеленел") - в итоге отчёт честно покажет 3 пропущенных и один успешных прогон, но нужно ли это нам? По-хорошему в итоговом отчёте "для начальства" нам интересен только последний раз, именно он идёт в зачёт. Итого появляется задача убирать "ложные" прогоны из отчёта. Как обычно"всё придумали до нас". Добавлю что отфильтровывать лишнее можно по-разному и в разных местах:
- #onFinish() в собственной реализации TestListenerAdapter;
- @AfterMethod/Group/Suite в базовом классе;
- #retry() в реализации IRetryAnalyzer. Но! Это будет работать только для тестов которые так и на "позеленели" в процессе перепрогона.

Выбирайте кому что и когда.

Почему падают авто-тесты?

Летним ветром навеяло:
Почему падают авто-тесты, какие типовые причины и вообще - доколе? Я бы выделил четыре группы причин:
1. "Битая" функциональность, т.е. таки изъян в тестируемой системе;
2. "Поломанные" тесты - кто-то что-то улучшил, изменились локаторы, поменялась логика работы системы ... ;
3. Что-то нездоровое было с окружением: сеть(задержки-огнестены-впн-ы и т.д.), драйверы, электропитание, админы празднуют Новый Год ... ;
4. НЁХ - "неведомое ёлочное художество". Упали потому что упали, жалко что ли?

ИИ всё ближе / AI is closing.

Разум изнурённый борьбой с постоянными падениями на СИ, протухаущими данными и прочими прелестями "взрослого проекта с длинной историей" начинает требовать внедрения ИИ в тесты - "что оно как-то там само разруливала мелкие падения и вопросы типа 'откуда брать кошерные данные прямо вот сейчас'". Главное чтоб потом код тестов не стал на порядок сложнее кода тестируемого приложения.

-------------

All those failing tests and suddenly became invalid data are so frustrating that engineer's mind strats to demand an AI in the test automation solution - just to decide-on-the-fly what-to-do and where-to-go if something went wrong in runtime. The main concern - test automation code should not be more complex than AUT's one.