Где инициализировать пейджи  - в предке тест-класса или в самом тест-классе
Всім привіт.
стосовно зауваження по ініціалізації пейджи в базовому тест класі https://www.refheap.com/120326
"Соображения -
   даже в рамках тестов одного приложения не факт, что в разных тест-классах понадобидся одна и та же пейджа
   не хочется портить универсального предка для тест-класса
   хочется быть более KISS - чтобы не приходилось из тест-класса искать - что за пейджа у нас "

Я залишусь при свої думці. В захист своєї позиції, що досить зручно коли ініціалізація всіх пейджів знаходиться в одному класі. А те що з тестового класу не видно що саме за пейджа, то у випадку комплексного веб додатку це вирішується лаконічними назвами змінних в парент тест-класі і звикається до цього досить швидко.

yashaka [10:26 PM]
ти порушуєш деякі принципи
наприклад:
Single Responsibility Principle

твій бейс клас починає відповідати і за пейджі…
хоча перед цим він відповідав за інше…
А тепер він вже став “контейнером пейджів" (edited)
більше того, ім’я твого класу нічого не каже про те що він є контейнером пейджів
такий код - є магічним - тому що приховує важливу інформацію
те що до цього можна звикнути - бо запам’ятати - це погана практика…
бо колись твоя пам’ять зламається, якщо ти будеш забагато магії тримати в голові
тести мають бути очевидними - це основне правило…
і це значить що все що стосується тест логіки - має бути в тесті, навіть якщо воно дублюється
тут KISS важливіше за DRY
якщо тобі так сильно хочеться тримати всі пейджі в одному місці - то для цього варто створити окремо клас - контейнер пейджів
назвати наприклад його App
і вже через нього мати доступ до цих пейджів…
можливо у вигляді статичних просто змінних
щоб писати App.todoMVCPage
ну чи просто
App.page
оскільки у нас інших пейджів немає…
так що ти звісно можеш робити як завгодно, але при такому рішенні ти отримаєш не done а accepted :slightly_smiling_face:
бо ми таки не згодні з таким варіантом :slightly_smiling_face:
якщо хочеш “зручності”
то або створи окремо контейнер пейджів
або забери з бейс теста пейджу і запхни в базовий тест клас з відповідним іменем
типу AtTodoMVCPageTest
щоб було зрозуміло за що цей клас відповідає (edited)

але можеш ще нас переконати :slightly_smiling_face: якщо знайдеш аргументи :slightly_smiling_face:

>  А те що з тестового класу не видно що саме за пейджа, то у випадку комплексного веб додатку це вирішується лаконічними назвами змінних в парент тест-класі
не зрозумів чому “лаконічні назви” допомагають “видимості” :slightly_smiling_face:
проблема все одно є, і “я все запам’ятаю бо назви лаконічні і у мене хороша пам’ять” - це якийсь заслабкий аргумент
не у всіх хороша пам’ять… плюс тести сапортяться часто тими хто їх не писав, наприклад програмістами - їх теж ти змусиш запам’ятати все що живе в базовому класі?

> що досить зручно коли ініціалізація всіх пейджів знаходиться в одному класі
“досить зручно” це не аргумент
аргументом було б щось типу “це зручно тому що… “
ну і знову ж таки… вище я писав - що "одне місце” можна реалізувати і іншим способом, більш “безпечним” і простим, не вимагаючим великих затра пам’яті всієї команди

julia.v.iluhina [10:38 PM]
Привет)
я кстати - так и не поняла - какие плюсы ты получаешь при таком подходе
что в этом такого лучшего или более удобного?

yashaka [10:40 PM]
з приводу зручності - він хоче сказати що є “одна точка доступу” до всіх вже наперед ініціалізованих пейджів…
але знову ж таки… сумнівна зручність тримати їх в базовому классі…
мати до них доступ через окремий обьект контейнер типу App
чи Pages
імхо набагато зручніше тому що це явно
і через крапочку можна отримати доступ тільки до пейджів, а не до ще чогось, що може жити в тому ж базовому класі
при цьому хоча такий варіант з контейнером - я б прийняв як для done
я все одно не вважаю це добрим рішенням
бо імхо явно в тесті показати з якими пейджами іде робота  - набагато більш очевидніше і інформативніше ніж в кожен тест “передавати всю пачку пейджів"

julia.v.iluhina [10:41 PM]
т е мы заранее считаем - что нам в любых тест-классах нужен одинаковый набор пейджей?

yashaka [10:42 PM]
ну… ми не вважаємо - але це так, є мінусом цього рішення :slightly_smiling_face:
що ми трохи “запудрюємо мозги” надлишковою інформацією :slightly_smiling_face:
це як таскати з собою повний мішок інструментів “на всі випадки життя” :slightly_smiling_face:
хоча можна було б передбачити що сьогодні тобі знадобиться тільки те то і те то

student [10:45 PM]
Ну єдина точка доступу App у мене на проекті використовується)

yashaka [10:46 PM]
ну я радий за твій проект, але не за твоє рішення домашки :slightly_smiling_face:
тому що у ньому поки що не так )
і доречі… поки у нас всього одна пейджа…
що означає - що нам App - якби трохи зайвий :slightly_smiling_face:

student [10:48 PM]
тільки хотів це писати)
хех

yashaka [10:48 PM]
і можна вважати що сам TodoMVC - і є єдиною точкою входу)
таке… враховуючи що це “єдина точка входу і так” - то можна в принципі і винести її кудись в базовий тест клас…
але все одно - треба створити його окремо, з гарним іменем типу AtTodoMVCPage
вже й плюс заодно і винести туди прекондішен відкриття сторінкиі очистки даних…
але знову ж таки… як на мене - все це трохи занадто складно як для тестів для еплікейшена тільки з одною сторінкою…
таке...

student [10:52 PM]
Тоді якщо пейджа одна, чому її інітити в різних класах?
При переході до більш складного рішення і в у випадку жорского розділення логіки(в одних тестах зазвичай одні пейджі), то було б здається норм.
Прекондішини вже використовуються з хелпера, того виходить городити окремий клас в ієрархії наслідування заради пейджи тільки....

yashaka [10:53 PM]
> Тоді якщо пейджа одна, чому її інітити в різних класах?
тому що це ООП
а в ньому нормально все інітити скрізь де потрібно заюзати
якби це було модульне програмування - то там не треба нічого інітити

> Прекондішини вже використовуються з хелпера, того виходить городити окремий клас в ієрархії наслідування заради пейджи тільки....
ну так… правильно мислиш…
ієрархіх наслідування - це складно, це не КІСС
але точно така сама логіка з вбудовою пейджі в BaseTest
ти теж ускладнюєш ієрархію наслідування - тим що “роздуваєш” один з класів в цій ієрархії, при цьому порушуючи SRP
таке… тут звісно можна довго сперечатися...