t.me/atinfo_chat Telegram группа по автоматизации тестирования

Как содержать тесты в актуальном состоянии или утилита для проверки @Ignore тестов с привязкой к JIRA

Теги: #<Tag:0x00007f9b04119df0>

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

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

  1. Автоматизирую кейс
  2. Тест падает
  3. Создаю багу в джире (в данном случае это важно, так как утилитка заточена под работу с джирой, но никто не мешает повторить такое для других багтрекеров)
  4. В теле аннотации @Ignore я пишу id созданного бага
  5. Проходят года, баг фиксится, но я забываю его включить в регресии
  6. Вижу, что набралось слишком много заигнореных тестов и запускаю утилиту:
public class GetTestsWhichCouldBeEnabled {
public static void main(String[] args) throws Exception {
    Pattern MY_PATTERN = Pattern.compile(<jira id pattern>);
    String packageName = <test sources package>;
    Reflections reflections = new Reflections(packageName );
    Set<String> issues = new HashSet<>();
    Set<Class<?>> allClasses = reflections.getTypesAnnotatedWith(Ignore.class);
    reflections = new Reflections(new ConfigurationBuilder()
            .setUrls(ClasspathHelper.forPackage(packageName ))
            .setScanners(new MethodAnnotationsScanner()));
    Set<Method> allMethods = reflections.getMethodsAnnotatedWith(Ignore.class);
    for (Class klass : allClasses) {
        String value = ((Ignore) klass.getAnnotation(Ignore.class)).value();
        Matcher m = MY_PATTERN.matcher(value);
        while (m.find()) {
            issues.add(m.group());
        }
    }
    for (Method method : allMethods) {
        String value = method.getAnnotation(Ignore.class).value();
        Matcher m = MY_PATTERN.matcher(value);
        while (m.find()) {
            issues.add(m.group());
        }
    }
    JiraConnector connector = new JiraConnector();
    for (String issue : issues) {
        Issue jIssue = connector.issue(issue);
        String status = jIssue.getStatus().getName();
        if (status.toLowerCase().equals("closed")) {
            System.out.println(issue);
        }
    }
}

Подключение к JIRA, оно же JiraConnector:

    public class JiraConnector {
    private IssueRestClient issueRestClient = null;
    protected static final Logger logger = Logger.getLogger(JiraConnector.class);

    public JiraConnector() {
        Properties properties = new Properties();
        try {
            properties.load(new FileInputStream("src/test/resources/jira.properties"));
        } catch (IOException e) {
            logger.error("Can't load 'jira.properties'");
        }
        String url = System.getProperty("url", properties.getProperty("url"));
        String login = System.getProperty("login", properties.getProperty("login"));
        String pass = System.getProperty("pass", properties.getProperty("pass"));
        final AuthenticationHandler handler = new BasicHttpAuthenticationHandler(login, pass);
        JiraRestClient client = new JerseyJiraRestClient(URI.create(url), handler);
        issueRestClient = client.getIssueClient();
    }

    public Issue issue(String id) {
        return issueRestClient.getIssue(id, new NullProgressMonitor());
    }
}

Если в JIRA у нас есть проекты Project1 и Project2, в которых id тасков и багов начинаются с PROJ1 и PROJ2 соответственно, то паттерн с вероятностью 99% будет иметь такой вид:

Pattern.compile("(PROJ1|PROJ2)([+-])(\\d+)")

необходимые dependency:

  <dependency>
        <groupId>com.atlassian.jira</groupId>
        <artifactId>jira-rest-java-client</artifactId>
        <version>1.0</version>
    </dependency>
    <dependency>
        <groupId>org.reflections</groupId>
        <artifactId>reflections</artifactId>
        <version>0.9.9-RC1</version>
        <exclusions>
            <exclusion>
                <groupId>dom4j</groupId>
                <artifactId>dom4j</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
3 Симпатий

Спасибо, давно хотел пощупать Jira REST API. Только вопрос: зачем дизейблить тесты в случае наличия бага?

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

Или этот шаг вызван другими причинами?

честно говоря, я, проработав не на одном проекте, еще ни разу не видела, чтобы кто-то из разработчиков заглядывал в CI тестеров. Это не значит, что такого нет, просто обычно выделяли отдельно окружение со своими агентами и никому, кроме тестеров до этого окружения дела нет. А меня фейлящиеся тесты несколько отвлекают, да и время занимают, которое и так дорого :smile:

Про свой опыт:

На одном из проектов была хорошая практика гонять отмеченные дефектами тесты отдельной под-джобой — в рамках регрессионного тестирования / верификации нового билда.

В связке с отображением статусов из JIRA в отчетах, это давало фактически автоматическую верификацию дефектов тестами.

2 Симпатий

У нас, например, для бекэнд девелоперов начинают вводить практику пре-коммит анализа UI-тестами. А сами UI-девелоперы требуют ежедневных писем от CI с результатами, чтобы получать быстрый фидбек об имеющихся проблемах. Для них профит автоматизации как раз состоит в том, чтобы информация поступала быстрей, чем от команды мануальщиков (работаем по чистому скраму).

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

Так что мы перешли на схему: смоук - несколько раз в день (ввиду частых билдов), фул регрешен - 1-2 раза в неделю, когда скапливается достаточное кол-во фич / багофиксов. Ну и красных огоньков никто не пугается. Пугаться надо когда их вообще нет. :blush: Работая по agile нереально получать 100% pass rate в автомейшене. Всегда будет что-то ломаться, меняться, допиливаться. Да и тесты ведь тоже будут расширяться.

1 Симпатия

Скажите, пожалуйста, а сколькоу вас тестов?

это к кому вопрос?:slight_smile:

+1 к тому, что не стоит дизейблить фейленные тесты. Иначе зачем тогда они вообще нужны?))
С jira прикольный вариант, тоже как то пробовали схожий вариант. Там вообще апи богатый

К вашему)
Долго не отвечала - не увидела ответ.
Интересно сколько у вас тестов, что есть необходимость дизейблить зафейленные.
Сколько всего и сколько зафейленных, общие метрики скажите, пожалуйста.

4000+ всего (около 2500 - ежедневно ~20 часов, полностью все в выходные 30 часов)
~ 15-20 новых фейлов в день из-за багов/изменений в верстке/изменений в логике
~ 70 заигнореных из за багов разной приоритетности

1 Симпатия

@tymoschuk_jane хотел попросить оформить этот пример в github плиз чтобы код сохранить, если не сложно конечно. http://atinfo.github.io/at.info-knowledge-base/