Резюме зустрічі 17.11.15

Відео

Валідація email в контролері

🕒 [00:45 - 19:30]

• треба розбити application context на рівні, замість сервісів використевувати моки; [1:30 - 2:30]
• щоб працювала валідація, треба:
  • додати @Validated на клас контролера; [3:00]
  • додати бін MethodValidatorPostProcessor; [3:54]
• Exceptions handler - перехоплює виключення: [6:35]
  • додати @ControllerAdvice на клас контролера; [8:20]
  • додати @ExceptionHandler на метод; [9:30]
  • повертаємо статус BAD_REQUEST; [15:00]
  • повертаємо строку з помилкою;

Створення тесту для сервісу

🕒 [19:30 - 57:00]

• SubscriberServiceTest();
• MyBatis*ServiceTest - погана назва; [12:20]
• створення SubscriberService; [32:20]
• структура тесту: [39:00]
  • given
  • when
  • then
• Given - When - Then, Agile Alliance
• GivenWhenThen, Martin Fowler
• Given-When-Then, Wikipedia
• How to get the most out of Given-When-Then, Gojko Adzic
• acceptance (functional) tests - тестування всього application (REST API); [50:00]
• integration tests - контролер + сервіс + БД; [52:00]
• в юніт-тестах треба перевіряти всю множину вхідних параметрів, в інтеграційних - достатньо взяти один валідний варіант і один невалідний;

Відповіді на запитання

🕒 [57:20 - ]

[58:27] Нужно ли откатывать необдуманно принятый пр из мастера, если в нем были допущены необоснованные изменения существующих ченчсетов, нарушен порядок нумерации новых ченчсетов относительно забитых в Liquibase changeset LOG в wiki, и множество других ароматных недоработок?

• [1:02:21] Конструктивний зворотній зв'язок, "критикуєш - пропонуй";

[1:07:57] Как правильно поступать, если нужен функционал из другого бренча? Ждать пока он попадёт в мастер или мержить его себе, но как тогда быть с коммитом, ведь в него попадёт и “другой” бренч?

• мерджити гілки;
• робити заглушки;