Ввожу новый хэштег - #этоневажно. Дело в том, что я уже годы наблюдаю упертое желание потешить свое ЧСВ казалось бы важными постулатами в автоматизации, но большинство из них на самом деле не важны.
Сегодня рассмотрим классику - PageObject (тут и далее как обычно все на Java).
Что важно для PageObject?
1) PageObject объект должен создаваться максимально просто - читай, через
new (безо всяких PageObjectFactory)2) Он должен быть immutable и никогда не иметь никакого shared mutable state - читай, все поля
final , а static - только для immutable констант 3) Он должен использовать композицию, а не наследование для расширения функциональности (то есть, если у нас есть
LoginPage с двумя полями логин и пароль, и RegistrationPage с тремя полями - логин, пароль, повторипароль, то мы не делаем RegistrationPage extends LoginPage). Вообще, наследование почти никогда не нужно в тестах на самом деле.Все остальное, что я годами читаю в умных чатах по автоматизации, да и на code-review - не важно. Примеры:
- Стэпы должны быть в отдельном классе! Или наоборот - стэпы должны быть только в PageObject! - это вообще не имеет никакого значения, лишь бы было где-то прописано прямо в ридми. Никакой технической разницы нет, разве что вам приятно писать больше отдельных step-классов;
- Селектор должен быть CSS ! или XPATH!. Селектор вообще никому ничего не должен. В реальной жизни к нему только одно требование - селектор не должен быть всратым. Но это не зависит от того CSS он или XPATH
- Методы должны возвращать this! Или не должны! Или должны, но не всегда! - это не влияет никак ни на скорость написания тестов, ни на поддерживаемость, ни ну удобство рефакторинга.
- При композиции ты должен дублировать все методы вложенного объекта / Ты должен просто написать геттер! - можно и так и так
- Ассертов в пэйдж обжекте быть не должно - встречал и такое 🥲
- Имена полей должны начинаться со слова element! Или заканчиваться им!
и т.д. и т.п.
Обращайте внимание только на то, что действительно (технически) важно: иммутабельность, простота инициализации, композиция вместо наследования.
UPDATE от iLesnykh:
Бизнесу так-то вообще на весь код плевать, главное чтоб работало и деньги приносило. Но это же не делает код или то, какой он, неважным.
Думаю нет понятия "не важно". Важно всё, что важно команде. Просто есть разные приоритеты. Тут как в жизни: есть базовые потребности (допустим, Дима их описал выше – иммутабельность, композиция, инициализация) – и если самое важное покрыто, то мы начинаем искать смысл в менее важном (типа еда и жильё есть, next step – а какой бренд сумочки или сколько высота потолков). И это тоже своего рода важно, просто не важнее первого и не в ущерб балансу скорость/качество.