Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add test cases to verify dateAnswered #353

Open
wants to merge 1 commit into
base: devel
Choose a base branch
from

Conversation

kosaniak
Copy link
Contributor

@kosaniak kosaniak commented Oct 28, 2016

This change is Reviewable

@mykhaly
Copy link
Contributor

mykhaly commented Oct 31, 2016

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.


op_robot_tests/tests_files/openProcedure.robot, line 747 at r1 (raw file):

  ...      answer_question_to_tender
  [Setup]  Дочекатись синхронізації з майданчиком  ${viewer}
  Отримати дані із тендера  ${viewer}  ${TENDER['TENDER_UAID']}  dateAnswered  ${USERS.users['${provider}'].tender_question_data.question_id}
  1. Таким чином не відбудеться перевірки, чи дата відображається правильно. Пропоную зберегти локально дату подання відповіді і при перевірці порівнювати зчитану дату зі збереженою з якоюсь точністю (+-1 хвилина або період синхронізації майданчика).
  2. І по ходу очікувати на синхронізацію з майданчиком тут немає потреби, бо цей тесткейс завжди буде йти після попереднього, в якому та синхронізація вже відбулася.

Comments from Reviewable

@selurvedu
Copy link
Contributor

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.


op_robot_tests/tests_files/openProcedure.robot, line 747 at r1 (raw file):

Previously, mykhaly (Yurii Mykhalchuk) wrote…

  1. Таким чином не відбудеться перевірки, чи дата відображається правильно. Пропоную зберегти локально дату подання відповіді і при перевірці порівнювати зчитану дату зі збереженою з якоюсь точністю (+-1 хвилина або період синхронізації майданчика).
  2. І по ходу очікувати на синхронізацію з майданчиком тут немає потреби, бо цей тесткейс завжди буде йти після попереднього, в якому та синхронізація вже відбулася.
1) Скоріше варіант з "період синхронізації майданчика", але так, щоб дельта (`delta = server_date - local_date`) була не меншою за нуль, і не більшою за період синхронізації майданчика (`0 ≤ delta ≤ timeout_on_wait`).

BTW, для цього, мабуть, в compare_date (service_keywords.py, L68) треба поміняти рядок delta = (left - right).total_seconds() на delta = (right - left).total_seconds(), бо зліва в нас завжди локальна дата, і тоді виклика́ти compare_date з аргументом absolute_delta=False (лише для цих тесткейсів з dateAnswered).

BTW, можна і такий варіант: -60 ≤ delta ≤ timeout_on_wait. @mykhaly, як тобі?

  1. Може й так, тут і нижче, але є одне але. Якщо якісь тесткейси будуть виключені/не включені, то воно стає потрібним, і не тільки тут. Очікувати більше ніж треба воно все одно не буде завдяки ${LAST_MODIFICATION_DATE}.

Comments from Reviewable

@mykhaly
Copy link
Contributor

mykhaly commented Oct 31, 2016

Review status: all files reviewed at latest revision, 2 unresolved discussions.


op_robot_tests/tests_files/openProcedure.robot, line 747 at r1 (raw file):

Previously, selurvedu wrote…

  1. Скоріше варіант з "період синхронізації майданчика", але так, щоб дельта (delta = server_date - local_date) була не меншою за нуль, і не більшою за період синхронізації майданчика (0 ≤ delta ≤ timeout_on_wait).

BTW, для цього, мабуть, в compare_date (service_keywords.py, L68) треба поміняти рядок delta = (left - right).total_seconds() на delta = (right - left).total_seconds(), бо зліва в нас завжди локальна дата, і тоді виклика́ти compare_date з аргументом absolute_delta=False (лише для цих тесткейсів з dateAnswered).

BTW, можна і такий варіант: -60 ≤ delta ≤ timeout_on_wait. @mykhaly, як тобі?

  1. Може й так, тут і нижче, але є одне але. Якщо якісь тесткейси будуть виключені/не включені, то воно стає потрібним, і не тільки тут. Очікувати більше ніж треба воно все одно не буде завдяки ${LAST_MODIFICATION_DATE}.
2) В тесткейсів однакові теги. А кожен додатковий прогін зайвого коду це додатковий cpu time, а час - це гроші :) Але то так, не принципово. 1) Явважаю, що оптимальним варіантом буде порівняння з `absolute_delta=True` і `delta=60`, бо: - чому `delta=60` -> майданчик мусить дані постити майже миттєво (тобто, якщо він запитання подає довше хвилини, то хай девелопери майданчика оптимізують код), а підтянувати зміни з цбд може раз на `timeout_on_wait`. - чому `absolute_delta=True` -> щоб не запарюватися з якимись змінами до **compare_date** і тому, що нам, по-суті, байдуже, чи питання буде подано трохи раніше (не можу придумати, як би то таке вийшло раптом) чи трохи пізніше. Головне, щоб відрізнялося від нашого часу менше, ніж на хвилину.

op_robot_tests/tests_files/openProcedure.robot, line 866 at r1 (raw file):

  ...      viewer
  ...      ${USERS.users['${viewer}'].broker}
  ...      answer_question_to_item

answer_question_to_lot.


Comments from Reviewable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants