История изменений

Может, сможете подсказать, пожалуйста, по архитектуре автотестов какие-то основные моменты?

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

Как их грамотно организовать? Какие паттерны/фреймворки лучше всего использовать?

Мы использовали JUnit (плюс свой «runner»), т.к. с ним очень удобно работать из среды разработки. Здесь главное, чтобы осталась возможность работать с тестами (запустить один тест или один метод теста) из среды разработки - это очень, очень важно.

В принципе насколько я понял пригодятся PageObject’ы (который будет повторять структуру, иерархию UI тестируемого ПО), DataProvider’ы (для формирования/скармливания тестовых данных непосредственно в сами тесты), сами тесты наверное было бы неплохо писать в виде наборов тест-сьюитов и далее код в виде эдаких тест-кейсов (возможно, здесь хорошо подойдёт какой-нибудь BDD фреймворк для этого).

Тут напишу на правах ИМХО. 9 лет назад был один очень хороший доклад на тему автотестов - Alexandre Iline Rit 2010 Java Fxui. К сожалению, я видео не нашел - только слайды, но может Вас посетит удача...

Так вот: у тестирования GUI есть несколько очень важных аспектов:

1. Не делайте иерархию страниц (PageObject-ы и т.п.): в UI эффективным механизмом является композиция, а не наследование

2. Не повторяйте иерархию вашего разработанного ПО (мы же ведём речь о тестировании чёрного ящика?)

3. Для упрощения написания кода - пишите высокоуровневые «операторы». Например, раз у страницы есть «шапка», то создайте класс PageHeaderOperator, который позволит работать с этой шапкой (вызывать меню сайта, получать различные надписи и всё остальное). Если есть кнопка «логин» - сделайте LoginOperator, у которого будут методы login(user,password), logout(), status(). И так далее. Конечную сборку делайте уже только в самом тестовом методе.

4. Общие вещи можно и нужно вынести в суперкласс автотеста (например, можно создать AbstractAuthenticatedPageTst, который будет автоматом перед каждым тестом проверять, что пользователь залогинен и логиниться, если ещё нет). Большего в суперкласс я за свою практику так и не вынес :) У автотестов глубина иерархии сильно меньше в отличии от операторов.

В общем решили всё-таки использовать котлин, там вроде в качестве BDD-фреймворка есть Kirk. Что скажете?

Не смогу подсказать, т.к. котлином не пользуюсь. Вот что точно знаю - фреймворк и среда запуска вторичны, если решены задачи запуска на CI сервере и в IDE. Берите то, что знают ваши программисты/тест-автоматизаторы.

P.S. Приготовьтесь сразу быть готовым считать, сколько вы тратите на написание и поддержание автотестов и сколько при этом экономите. Экономика здесь очень важна. Ну и 100% покрытия автотестами я не видел никогда. Даже 60%-го.

Может, сможете подсказать, пожалуйста, по архитектуре автотестов какие-то основные моменты?

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

Как их грамотно организовать? Какие паттерны/фреймворки лучше всего использовать?

Мы использовали JUnit (плюс свой «runner»), т.к. с ним очень удобно работать из среды разработки. Здесь главное, чтобы осталась возможность работать с тестами (запустить один тест или один метод теста) из среды разработки - это очень, очень важно.

В принципе насколько я понял пригодятся PageObject’ы (который будет повторять структуру, иерархию UI тестируемого ПО), DataProvider’ы (для формирования/скармливания тестовых данных непосредственно в сами тесты), сами тесты наверное было бы неплохо писать в виде наборов тест-сьюитов и далее код в виде эдаких тест-кейсов (возможно, здесь хорошо подойдёт какой-нибудь BDD фреймворк для этого).

Тут напишу на правах ИМХО. 9 лет назад был один очень хороший доклад на тему автотестов - Alexandre Iline Rit 2010 Java Fxui. К сожалению, я видео не нашел - только слайды, но может Вас посетит удача...

Так вот: у тестирования GUI есть несколько очень важных аспектов:

1. Не делайте иерархию страниц (PageObject-ы и т.п.): в UI эффективным механизмом является композиция, а не наследование

2. Не повторяйте иерархию вашего разработанного ПО (мы же ведём речь о тестировании чёрного ящика?)

3. Для упрощения написания кода - пишите высокоуровневые «операторы». Например, раз у страницы есть «шапка», то создайте класс PageHeaderOperator, который позволит работать с этой шапкой (вызывать меню сайта, получать различные надписи и всё остальное). Если есть кнопка «логин» - сделайте LoginOperator, у которого будут методы login(user,password), logout(), status(). И так далее. Конечную сборку делайте уже только в самом тестовом методе.

4. Общие вещи можно и нужно вынести в суперкласс автотеста (например, можно создать AbstractAuthenticatedPageTst, который будет автоматом перед каждым тестом проверять, что пользователь залогинен и логиниться, если ещё нет). Большего в суперкласс я за свою практику так и не вынес :) У автотестов глубина иерархии сильно меньше в отличии от операторов.

В общем решили всё-таки использовать котлин, там вроде в качестве BDD-фреймворка есть Kirk. Что скажете?

Не смогу подсказать, т.к. котлином не пользуюсь. Вот что точно знаю - фреймворк и среда запуска вторичены, если решены задачи запуска на CI сервере и в IDE. Берите то, что знают ваши программисты/тест-автоматизаторы.

P.S. Приготовтесь сразу быть готовым считать, сколько вы тратите на написание и поддержание автотестов и сколько при этом экономите. Экономика здесь очень важна. Ну и 100% покрытия автотестами я не видел никогда. Даже 60%-го.