julia_v_iluhina

Untitled

Oct 23rd, 2016
76
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
Java 8.76 KB | None | 0 0
  1.  public static void prepareTasks(Task... tasks) {
  2.  
  3.         if (!url().equals("c")) {
  4.             open("https://todomvc4tasj.herokuapp.com/");
  5.         }
  6. /*
  7.     url().equals("c"))?
  8.  
  9.     подправь)
  10. */
  11. *********************
  12. public void givenAtAll(GivenHelpers.Task... tasks) {
  13. /*
  14.     Почему не Task... tasks ?
  15. */
  16. ***************************
  17. @Test
  18.     public void tasksLifeCycle() {
  19.         prepareTasks();
  20. /*
  21.     лучше быть последовательным)
  22.  
  23.     в тест-методах - вызываем гивен-методы
  24.  
  25.     технически - конечно безразлично
  26.  
  27.     но лучше принимать однородные решения
  28.     а иначе - зачем мы вообще реализовывали givenAtAll(GivenHelpers.Task... tasks) ?
  29.  
  30.     собственно - ради этого
  31.     чтобы во всех тест-методах мы оперировали гивен-методами
  32. */
  33. ***************************
  34.     @Test
  35.     public void editAtAll() {
  36.         givenAtAll(ACTIVE, "1");
  37.  
  38.         edit("1", "1 edited");
  39.         assertTasksAre("1 edited");
  40.         assertItemsLeft(1);
  41.     }
  42.  
  43.     @Test
  44.     public void editAtActive() {
  45.         givenAtActive(ACTIVE, "1");
  46.  
  47.         edit("1", "1 edited");
  48.         assertTasksAre("1 edited");
  49.     }
  50. /*
  51.     мы тестируем - одно действие в этих тестах
  52.  
  53.     разнообразь тестовые ситуации
  54.  
  55.     в одном методе - работаем с единственно таской
  56.     а во втором - со второй таской в списке
  57.  
  58.     писала про это в http://pastebin.com/zaC9GVAy, строки 176-183
  59. */
  60. **********************************
  61. http://joxi.ru/v29WjP9hG15WNr
  62. /*
  63.     не вижу таких тест-методов
  64.  
  65.     тут - тоже - как и во всех фиче-тестах
  66.  
  67.     тестовая ситуация - и активные таски, и закомпличеные + на нужном фильтре
  68.     тестовое действие - переход на нужный фильтр
  69.     проверки - списка тасок и items left
  70.  
  71.     такой подход - когда мы фильтеринг будем проверять и на активных тасках, и на закомпличеных -
  72.     проверит фильтеринг качественно - мы увидим как операция влияет на отображение тасок с любыми статусами
  73.  
  74. */
  75. **************************
  76.     @Test
  77.     public void completeAtAll() {
  78.     /*
  79.         тестируем не completeAtAll
  80.         а completeAllAtAll
  81.     */
  82.         givenAtAll(ACTIVE, "1", "2");
  83.  
  84.         toggleAll();
  85.         assertTasksAre("1", "2");
  86.         assertItemsLeft(0);
  87.         /*
  88.             с учетом тестов для переходов по фильтрам - єтих проверок достаточно
  89.             если смотреть на все фиче-тесты в комплексе - это будет ок
  90.         */
  91.         filterCompleted();
  92.         assertTasksAre("1", "2");
  93.         /*
  94.             а если хочется таки быть точнее - то можно так
  95.             но - тогда и filterCompleted - это еще одно тестовое действие
  96.  
  97.             и так - получился не фиче-тест
  98.             а такой небольшой е2е-тест
  99.  
  100.             если так делать - это надо учесть в покрытии (для такого перехода - уже не делать фиче-теста)
  101.             ну и в названии тест-метода надо отразить - что не только completeAll покрыли
  102.             но и переход на такой-то фильтр
  103.  
  104.             я вообще сторонник варианта с фиче-тестами)
  105.             но и такой вариант имеет право на жизнь
  106.         */
  107.     }
  108. ************************************************
  109.     @Test
  110.     public void reopenAtAll() {
  111.         givenAtAll(ACTIVE, "1");
  112.  
  113.         toggle("1");
  114.         /*
  115.             вообще-то тут мы закомпличиваем таску - т к в гивенах - мы создали активную
  116.             значит toggle = закомплитит
  117.  
  118.             еще в на уровне гивена - создавай закомпличеную таску
  119.         */
  120.         assertTasksAre("1");
  121.         /*
  122.             проверяй  items left - там где это возможно
  123.             тут - возможно
  124.         */
  125.     }
  126. **********************************
  127.     @Test
  128.     public void clearCompletedAtAll() {
  129.         givenAtAll(ACTIVE, "1", "2");
  130.  
  131.         toggleAll();
  132.         assertTasksAre("1", "2");
  133.         /*
  134.             мы тестируем - clearCompleted
  135.             потому - не надо уже покрывать toggleAll
  136.  
  137.             просто на уровне гивен-метода - создай пару тасок - кативную и закомпличеную
  138.             и дальше - выполняй clearCompleted();
  139.             и список тасок проверишь и  items left
  140.  
  141.             и в clearCompletedAtActive() - похожие проблемы
  142.             не забывай про разные тестовые ситуации)
  143.         */
  144.         clearCompleted();
  145.         assertTasksEmpty();
  146.     }
  147. ***********************************************
  148.    @Test
  149.       public void completeAtActive() {
  150.           givenAtActive(ACTIVE, "1");
  151.  
  152.           toggle("1");
  153.           assertTasksEmpty();
  154.           assertItemsLeft(0);
  155.           /*
  156.             тут  - уже точнее некуда)
  157.             точно надо останавливаться)
  158.  
  159.             если говорить про тест complete на all фильтре
  160.             то можно решить - что надо уточнить такие проверки
  161.  
  162.             то на других фильтрах - точно вот таких проверок достаточно
  163.           */
  164.           filterAll();
  165.           assertTasksAre("1");
  166.           /*
  167.             может ты как раз и хотела вот так допокрыть фильтеринг
  168.  
  169.             лучше вынеси в фиче-тесты
  170.             у них есть неоспоримое преимущество - каждая фича будет оттестирована независимо
  171.  
  172.             а вот в такой реализации - если тест упадет на первой операции
  173.             то вторую мы уже не оттестим
  174.  
  175.             сделали небольшое количество е2е и допокрыли все фиче-тестами - хорошая стратегия
  176.             и обеспечили хороший качественный фидбек по всем фичам
  177.             и проверили интеграцию - как мы в одном многошаговом сценарии работаем
  178.           */
  179.       }
  180. ************************************
  181.  
  182.     @Test
  183.     public void reopenAllAtCompleted() {
  184.         givenAtCompleted(COMPLETED, "1", "2");
  185.  
  186.         toggleAll();
  187.         assertTasksEmpty();
  188.         assertItemsLeft(2);
  189.         /*
  190.             и вот тут - останавливаемся
  191.         */
  192.         filterActive();
  193.         assertTasksAre("1", "2");
  194.     }
  195. *************************
  196.         @Test
  197.         public void confirmEditPressingOutsideAtCompleted() {
  198.  
  199.             givenAtCompleted(COMPLETED, "1", "2");
  200.  
  201.             startEdit("1", "1 edited");
  202.             $("#header>h1").click();
  203. /*
  204.     Неплохой выбор элемента - на чем кликнуть
  205.  
  206.     нам надо кликнуть на чем-то таком, что даст нам только смену фокуса и более ничего не будет происходить
  207.     но еще лучше - кликнуть на том, что мы уже используем
  208.     вот например $("#new-todo")
  209.     цель - оперировать меньшим количеством селекторов
  210. */
  211. ****************************************
  212. /*
  213.     смотри сама - может сразу это же подправляй и в следующих работах
  214.     или уже на уровне этой работы определимся
  215.     и дальше просто перенесешь это
  216. */
Advertisement
Add Comment
Please, Sign In to add comment