Комментарии 2
Про всем известный Page Object много, про менее известный Screenplay меньше, про два остальных вообще пол слова, даже без примеров. Зачем статья?
Утверждение «Архитектура портов и адаптеров направлена на то, чтобы убедиться, что вы используете принцип единой ответственности» крайне ошибочно:
1. Адаптер — пример простейшего шаблона проектирования. Не имеет за собой архитектуру;
2. Адаптер позволяет круг превратить в квадрат. Что тут может позволить убедиться «что вы используете принцип единой ответственности». В кривых руках круг превращается в колесо с полным нарушением SRP и адаптер позволяет это сделать.
В статье смешали понятия паттернов и реализации паттернов. Сами по себе паттерны на нарушают принципов(ни SOLID, ни DRY, ни каких бы там ни было). Они лишь содержат рекомендации и могут иметь разные реализации. Поэтому утверждать, что PageObject не соответствует SOLID, а Screenplay соответствует, я считаю некорректно. Все реализации PageObject, которые я видел(кроме собственной :)), нарушают SRP и DIP. В самом первом примере нарушены практически все принципы SOLID. Я думаю, если статью прочитает человек с большим опытом разработки, чем у меня, найдет нарушения и во втором.
Presenter First – это модификация model-view-controller (MVC) для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD):
1. MVC — не совсем паттерн, это способ организации кода(мое личное мнение, понимаю, что многие не согласятся);
2. это модификация «способа организации кода» для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD). Я честно несколько раз перечитал, но так и не понял, что Вы хотели сказать. Как может паттерн иметь цель «создание полностью протестированного программного обеспечения»? Паттерн решает проблему. Проблему «создания полностью протестированного программного обеспечения» решает разработчик, ни один паттерн ее не решит.
1. Адаптер — пример простейшего шаблона проектирования. Не имеет за собой архитектуру;
2. Адаптер позволяет круг превратить в квадрат. Что тут может позволить убедиться «что вы используете принцип единой ответственности». В кривых руках круг превращается в колесо с полным нарушением SRP и адаптер позволяет это сделать.
В статье смешали понятия паттернов и реализации паттернов. Сами по себе паттерны на нарушают принципов(ни SOLID, ни DRY, ни каких бы там ни было). Они лишь содержат рекомендации и могут иметь разные реализации. Поэтому утверждать, что PageObject не соответствует SOLID, а Screenplay соответствует, я считаю некорректно. Все реализации PageObject, которые я видел(кроме собственной :)), нарушают SRP и DIP. В самом первом примере нарушены практически все принципы SOLID. Я думаю, если статью прочитает человек с большим опытом разработки, чем у меня, найдет нарушения и во втором.
Presenter First – это модификация model-view-controller (MVC) для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD):
1. MVC — не совсем паттерн, это способ организации кода(мое личное мнение, понимаю, что многие не согласятся);
2. это модификация «способа организации кода» для организации кода и разработки с целью создания полностью протестированного программного обеспечения с использованием test-driven подхода к разработке (TDD). Я честно несколько раз перечитал, но так и не понял, что Вы хотели сказать. Как может паттерн иметь цель «создание полностью протестированного программного обеспечения»? Паттерн решает проблему. Проблему «создания полностью протестированного программного обеспечения» решает разработчик, ни один паттерн ее не решит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
4 лучших паттерна проектирования автоматизированного тестирования (и еще 86)