Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

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


(Jane Tymoschuk) #1

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

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

  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>

(Sergey Korol) #2

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

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

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


(Jane Tymoschuk) #3

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


(Dmitry Cheremushkin) #4

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

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

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


(Sergey Korol) #5

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

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

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


(Romanchuk Katerina) #6

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


(Jane Tymoschuk) #7

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


(sidelnikovmike) #8

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


(Romanchuk Katerina) #9

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


(Jane Tymoschuk) #10

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


(Mykhailo Poliarush) #11

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