В чем смысл выносить код в абстрактный класс и в чем смысл выносить код в интерфейс?

Что проверяют

Умеете ли вы применить ООП в своём тестовом фреймворке, а не пересказать определения. Для автоматизатора следом обычно спрашивают, как у вас устроены BasePage и BaseTest и почему не стоит наследовать всё от одного класса.

Как отвечать

Сформулируйте разницу через назначение:

• абстрактный класс: общая реализация и состояние для близких родственников. Экземпляр не создаётся, наследник обязан реализовать абстрактные методы. В Java наследовать можно только один класс;
• интерфейс: контракт «что умеет объект» без состояния экземпляра. Класс реализует сколько угодно интерфейсов. С Java 8 в интерфейсе есть default и static методы, с Java 9 приватные, поля бывают только константами.

Дальше примеры из автоматизации, они убеждают сильнее животных и птиц:

• BasePage: абстрактный класс хранит WebDriver, явные ожидания и общие методы вроде waitForLoaded(), а наследник реализует isOpened() для своей страницы;
• BaseTest: подъём и закрытие драйвера в @BeforeEach и @AfterEach, скриншот при падении;
• интерфейсы Selenium: WebDriver, JavascriptExecutor, TakesScreenshot это интерфейсы, ChromeDriver реализует их все, а тест зависит от WebDriver и не знает, какой браузер под ним. Так же удобно объявить свой PaymentClient и подменять реальный API заглушкой.

Если пишете на Python, аналоги это abc.ABC с @abstractmethod и typing.Protocol для структурного контракта.

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

Где спотыкаются

Утверждают, что интерфейс не может содержать реализацию. В современной Java и в C# начиная с 8-й версии это не так, и интервьюер это знает.

Строят глубокую иерархию BasePage → BaseFormPage → BaseModalPage и сваливают туда всё подряд. Через полгода любой page object тянет сотню ненужных методов. Шапку, таблицу, фильтры лучше делать компонентами и подключать композицией.

Не могут привести пример из своего проекта и отвечают про Animal и Dog. Для QA это сигнал, что фреймворк писал кто-то другой.