Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- http://joxi.ru/Rmzqpx8HW6wZnr
- /*
- чуть форматирование подправь)
- */
- *******************
- public class Texts extends CollectionCondition {
- protected List<String> expectedTexts = new ArrayList<>();
- protected List<String> actualTexts = new ArrayList<>();
- public Texts(String... expectedTexts) {
- for (String expectedText : expectedTexts) {
- this.expectedTexts.add(expectedText);
- }
- /*
- можно было сохранять переданные значения - в массиве
- public String[] expectedTexts;
- ....
- this.expectedTexts = expectedTextss;
- а можно и со списком работать)
- protected List<String> expectedTexts;
- ...
- this.expectedTexts = Arrays.asList(expectedTexts);
- кстати, при объявлении поля expectedTexts - можно его не инициализировать
- ведь мы в конструкторе это делаем)
- */
- }
- @Override
- public List<WebElement> check(List<WebElement> elements) {
- for (WebElement webElement : elements) {
- actualTexts.add(webElement.getText());
- }
- /*
- это не единственный кондишен, где нам придется собирать список текстов
- я бы реализовала где-то в Helpels - getTexts(List<WebElement> elements)
- */
- /*
- сначала - сравниваем размеры
- если не одинаковое количество ожидаемых текстов и элементов - уже кондишен не прошел
- */
- for (int i = 0; i < expectedTexts.size(); i++) {
- if (!actualTexts.get(i).contains(expectedTexts.get(i))) return null;
- /*
- и тут для if - согласно конвеншенс - нужны фигурные скобки
- */
- }
- return elements;
- }
- @Override
- public String expected() {
- return Arrays.toString(expectedTexts.toArray());
- }
- @Override
- public String actual() {
- return Arrays.toString(actualTexts.toArray());
- }
- /*
- у List<String> - уже все ок с toString()
- это для массива нам нужно использовать Arrays.toString(...)
- когда у нас был - один массив, а второй - список
- то список вот так выводить - через Arrays.toString(list.toArray()) - давало на то,
- что и список, и массив - в одном формате выводится
- в варианте - когда оба списка у нас - можно просто toString() использовать
- для обоих списков
- */
- **************************************************
- public interface LazyElement extends LazyEntity, WebElement {
- void click();
- /*
- click() - есть и у WebElement
- нету смысла объявлять тут одноименный метод
- технически это не запрещено, но чего-то дополнительного - не получим
- а вот такие - стоит добавить
- doubleClick
- hover
- setValue
- pressTab()
- pressEscape()
- эти все методы - можно реализовать вовращающими LazyElement
- чтоб они все - поддерживали chainable вызовы
- */
- *******************************************
- внесла правки согласно ревью. Не писала еще реализацию метов (нужно обязательно реализации всех методов писать?)
- public void submit() {
- }
- @Override
- public String getTagName() {
- return null;
- }
- ...
- /*
- все верно, нам нужно реализовать все эти методы
- это методы - WebElement-а
- нам нужно дождаться - или наличия элемента в DOM, или видимости
- зависит от того - что реализуем
- например - видимости стоит ждать - при какой-то интерактивной работе, или при получении какой-то информации
- которая нас интересует о видимом элементе (его координаты, текст и т п)
- в остальых случаях - достаточно, чтоб элемент был в DOM
- а после того, как дождались - надо у вебэлемента нашего - вызвать то же самое действие,
- что мы реализуем теперь для лейзи элемента
- аналогия с тем - что уже ты реализовала - полная
- просто нужно продолжить)
- ну еще по пути - почитать можно - что какой метод вебэлемента делает
- */
- ***************************************
- public class LazyWrappedWebElement extends AbstractLazyElement {
- /*
- в каждом из таких лейзи-классов - реализуй toString()
- я бы сюда передала кроме вебэлемента - еще и родительскую лейзи-сущность
- чтоб в toString() - рассказать - и откуда этот объект
- типа такого
- "WebElement " + element + " from " + parentEntity;
- */
- ***************************************
- public class LazyCollectionNthElement extends AbstractLazyElement {
- ...
- public LazyCollectionNthElement(By locator, int index) {
- ...
- @Override
- public WebElement getWrappedEntity() {
- return getDriver().findElements(locator).get(index);
- }
- /*
- не ограничивай себя только вариантом - когда коллекцию получили по локатору
- и затем элемент - по индексу
- можно побольше вариантов тут придумать)
- передавай родительскую коллекцию и индекс
- родительская коллекция - уже умеет возвращать список вебэлементов
- это не нужно и здесь повторять
- достаточно вызвать для родительской коллекции - ее getWrappedEntity()
- и уже у этого списка - вызывать get
- */
- @Override
- public String toString(){
- return locator.toString() + " with index " + index;
- }
- /*
- parentCollection.toString() + "[" + index + "]" ???
- предлагаю чуть лаконичнее)
- то же самое)
- */
- *****************************
- @Override
- public LazyCollection shouldHave(Condition<List<WebElement>>... conditions) {
- should(conditions);
- return this;
- }
- /*
- можно проще - return should(conditions);
- */
- *********************************
- @Override
- public LazyElement get(int index) {
- @Override
- public Iterator<LazyElement> iterator() {
- /*
- с реализацией - все ок
- только перенеси эти методы в абстрактный класс
- такая (или почти такая) реализация - будет для любой из коллекции
- потому - эти методы можно уже в абстрактном классе реализовать
- насчет get - думаю, по комментариям выше - ты уже сориентировалась)
- */
- **********************************
- public abstract class CollectionCondition extends AbstractCondition<List<WebElement>> {
- @Override
- public String identity() {
- return "elements";
- }
- }
- ...
- public abstract class ElementCondition extends AbstractCondition<WebElement> {
- @Override
- public String identity() {
- return "element";
- }
- }
- /*
- если так подумать - то этот метод identity() - все же свойство лейзи-сущности
- стоит этот метод объявить на уровне интерфейса LazyEntity
- реализовать в абстрактных классах
- и в AbstractCondition - уже использовать метод лейзи-сущности
- и в AbstractCondition метода identity() - уже не нужно объявлять
- тогда эти классы - CollectionCondition и ElementCondition
- а чтоб не смешивать в LazyEntity - такие разные методы
- то лучше метод identity() - объявить в новом интерфейсе DescribesEntity
- и уже LazyEntity - наследовать от DescribesEntity
- все будет по полочкам)
- примерно также - можно сделать на уровне AbstractCondition
- объявить методы
- String expected();
- String actual();
- в новом интерфейсе - DescribesResult
- от его наследовать - Condition
- и уже в AbstractCondition - не понадобится объявлений абстрактных методов
- для потомков ничего не изменится
- но зато разложим разный функционал по разным интерфейсам
- так четче обозначим разные по назначению наборы методов
- */
Advertisement
Add Comment
Please, Sign In to add comment