Java+testNG+maven
Ситуация у меня следующая, есть тест:
уровень наследования:
p2pPage extends CardForm
CardForm extends BaseTest
методы
enterSenderCardNumber
enterReceiverCardNumber
находятся в классе CardForm
остальные методы находятся в классе p2pPage
В общем-то, при форме записи, как показано на скрине выше - все работает.
Но, к этому я уже пришел, после того как пол дня пытался понять почему не отрабатывает такая форма записи:
при такой форме записи, у меня тест напрочь не видит методы, которые хранятся в классе p2pPage.
Кто-то может подсказать, пожалуйста:
почему форма записи 2 не работает?
Есть ли какой-то способ сделать так, чтобы вторая форма записи начала работать. Она удобней)
да, я это указал в описании темы.
Я уже понял, что т.к. он возвращает объект типа CardForm, то следующий метод вызванный по цепочке через точку, пытается работать с тем объектом который вернул предыдущий метод.
у меня теперь другой вопрос. А имеет ли смысл заморачиваться и возвращать из CardForm объект типа p2pPage или просто писать тесты в форме первой записи и не морочить себе голову?
p.s. CardForm это такой себе вспомогательный класс (это не страница.), методы которого используются на многих страницах, где необходимо заполнять форму карты.
Всегда использовал первый способ, по правде говоря, до недавнего времени не понимал толком, как работает второй способ. Да и дебажить в случае чего удобнее.
Еще, какой способ использовать, зависит от подхода, который ты используешь в тестах. В BDD подходе, где ты используешь Steps, такое мало подходит, если ты используешь без бдд, то там есть смысл использовать второй подход.
Это все делается дженриками, не надо ничего прерывать вообще). Даже навигируясь между страницами и закрывая одинаковый попап одним методом на разных страницах
почитал за дженерики, (никогда их не юзал), суть/принцип работы в принципе ясен, но непонятно только, какие преимущества реализация через дженерик даст для автотестов?
позволят вызывать методы как на втором вашем скриншоте. Посмотрите на мой скриншот, на нем пример, который решает вашу проблему. (никогда их не юзал) - листы это тоже дженерики, так что юзали
@Viktor_Yakushenko всё правильно сказал, можно в базовом классе определить тип дженерика и возвращать не текущий объект this, а приведенный к типу. Правда в Java есть кое-какие приколы с дженериками. Советую вот это видео по ним глянуть:
P.S. и да, писать на джаве без дженериков… скорее всего вы их сами не создавали, но точно применяли из стандартной библиотеки (листы, массивы, мапы, деревья и т.д.)
Хм… с дженериками в Java реально есть подвох. Возможно решения через них и не будет. Накидал у себя простенький пример и в нём дженерик не помог. Или я что-то на ночь глядя сделал не так.
Суть примерно как если бы мы через интерфейс пытались достучаться до методов объекта, которых нет в этом интерфейсе.
Так не будет работать. Если я правильно помню, то у C# и Java есть различия в реализации generic’ов.
Этот способ не работает по аналогии с тем, как в List<Number> мы не можем положить Integer, хотя он и наследуется от Number, точнее положить можем, но доставать будем назад только Number.
Это не совсем то. Если использовать строителя как у топикстартера, т.е. через точку вызывать методы у родительского и дочернего класса с возвратом на самого себя через this, то в этом случае метод должен иметь тип T и этот тип должен быть в описании класса. Но в java есть проверка на типобезопасность у дженерика. В итоге берется самый младший известный тип, т.е. для обычного T это будет Object, а для T extends CardPage это будет CardPade. Поэтому сама джава не даст вызвать методы наследника при таком приведении.
А вообще у ТСа все в куче и пейджы наследуют от BaseTest и т.д.
testomat.io управление авто тестами
