yashaka

Untitled

Feb 20th, 2017
146
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 5.93 KB | None | 0 0
  1. ========================================================================================================================
  2. ***
  3. .shouldHave(sizeGreaterThanOrEqual(1))
  4. .first();
  5.  
  6. шулд лишний
  7. селениде автоматом подождет именно такого же кондишена
  8.  
  9. ***
  10.  
  11. >>>>>>>> ты уверен? я помню у меня была проблема в рабочем проекте что буз шулда он кидал ArrayIndexOutOfBounds
  12. и я дописыванием шулда пофиксил это...подумал что методы типа size(), get(...) не триггерят поиск, и
  13. нужно говорить явно чего ему сначало подождать, чтоб потом взять
  14.  
  15. >>>>>> я 100 раз уверен :) size - не тригерит. Но get тригерит репоиск и ждет пока не будет нужное количество элементов. Также все операции над элементами ждут до визибилити. Такше findBy(condition) - при последующей операции - ждет до того момента пока по такому кондишену на будет найден элемент в коллекции.
  16. ========================================================================================================================
  17. не сильно читабельно получилось...
  18. я бы лучше завернул этот конструктор в другой класс
  19. типа
  20. new UnreadedEmails()
  21.  
  22. либо так... либо лучше как у тебя раньше было :)
  23.  
  24.  
  25. >>>>>>>> разве? посмотри еще раз, я там другие штуки переделывал, как по мне норм)
  26.  
  27. >>>>> сейчас выглядит лучше :) это похоже на то что я имел ввиду под "лучше как у тебя раньше было"
  28. хотя у тебя сейчас не совсем так... но стиль похож...
  29.  
  30. ну и что то меня коробит пока в этой реализации... нужно додумать что...
  31.  
  32.  
  33. =======
  34. public class Emails {
  35. ...
  36.  
  37. @Step
  38. public Emails all() {
  39. return new Emails();
  40. }
  41.  
  42. ну.... лучше просто return this
  43.  
  44. и получается что этот ментод вообще лишний..
  45.  
  46. вот знаешь... я думаю плохой идеей было делать эти методы не статическими... пускай лучше бы они статическими были...
  47.  
  48. а то как то конфузно слегка получилось...
  49.  
  50. по сути
  51.  
  52. @Step
  53. public Emails unreaded() {
  54. return new Emails("zE");
  55. }
  56.  
  57. @Step
  58. public Emails readed() {
  59. return new Emails("yO");
  60. }
  61.  
  62. это альтернативные "конструкторы"
  63.  
  64. а конструктор - это "статическая штука" по своей природе...
  65.  
  66. твой стиль был бы удобен если бы мы как то использовали поточный обьект this
  67. если бы ты как то брал то что есть в this и дополнительно его например фильтровал... и потом бы создавал на основе этого класс emails...
  68.  
  69. а так... лучше просто статическими эти методы делать...
  70.  
  71. еще... возможно стоило бы передавать бы в конструктор не кусок цсс - а целый локаторы в виде $$
  72. тогда бы эти статические конструкторы можно было бы запихнуть в InBox вообще...
  73.  
  74. как то не просто все :) нужно думать... подумай ты...
  75. а я еще скачаю твой проект, и сам поиграюсь...
  76.  
  77. ======
  78. public Emails(String cssClass) {
  79. String css = "tr" + (cssClass.isEmpty() ? "" : "." + cssClass);
  80.  
  81. не совсем сразу понятно что имеется ввиду под этим css
  82. возможно я бы дал более осмысленное имя
  83.  
  84.  
  85. public class Emails {
  86. ....
  87.  
  88. public Emails(String cssClass) {
  89.  
  90. и возможно сам cssClass я бы переименовал как то иначе, что бы было понятно какую роль играет этот cssClass...
  91. нужно помозковать.. я еще сам подумаю как лучше переименовать...
  92.  
  93. ====
  94.  
  95. public class Email {
  96. private final SelenideElement container;
  97.  
  98. public Email(SelenideElement container) {
  99. this.container = container;
  100. }
  101.  
  102. @Step
  103. public Email shouldHaveTopic(String topic) {
  104. container.find(".xY.a4W span").shouldHave(exactText(topic));
  105. return this;
  106. }
  107.  
  108. @Step
  109. public Email shouldHaveAuthor(String author) {
  110. container.find(".yX.xY .yW span").shouldHave(exactText(author));
  111. return this;
  112. }
  113. }
  114.  
  115. черт... обидно... ты тут сдублировал локаторы топика и автора...
  116. те что уже использовал тут:
  117.  
  118. public class Emails {
  119. ....
  120.  
  121. public Emails(String cssClass) {
  122. String css = "tr" + (cssClass.isEmpty() ? "" : "." + cssClass);
  123.  
  124. mailsContainers = container.findAll(String.format("tr.%s", css));
  125. authors = container.findAll(String.format("%s .yX .yW>span", css));
  126. topics = container.findAll(String.format("%s .y6 span[id*=':']", css));
  127. ...
  128. }
  129.  
  130. подумай как решить эту проблему...
  131.  
  132. ***
Advertisement
Add Comment
Please, Sign In to add comment