Зачем нужен static java - automated-testing

программирование java
#1

Прочитал о static, но не могу понять до конца его принцип работы и чем чревато его использование. Иногда в коде требуется (например при использовании enum) использование static переменных или методов. Почему коду вообще требуется статик? Для того чтобы можно было проще писать PageOne.setName()? И почему когда мы обращаемся к static, все что к нему “прикасается”, тоже превращается в static? Я понимаю что все элементы с этой припиской занимают в памяти место только один раз и в дальнейшем только она используется, но я не понимаю этого момента. Почему тогда все методы и переменные не делать static? Спасибо.

1 лайк
#2
  • Для вызова статического метода или филда не нужно создавать экземпляр класса.
  • Константы могут быть только статическими.
  • Значения статических филдов шарятся между всеми инстансами.
  • Статический импорт сокращает написание кода.
  • При помощи статики легче организовать централизованный доступ к нужному функционалу.
  • Статический контекст в основном используют в так называемых хэлперах.

Потому что основные концепции ООП предполагают осознание того факта, что принципиально разные по своей природе объекты не могут изменять свойства или управлять поведением друг друга. А родственные объекты должны уметь хранить “секреты”. Бездумное использование публичного статического контекста может привести к печальным последствиям.

Банальный пример: распространенная ошибка всех начинающих автоматизаторов, желающих распараллелить свои тесты со статическим потокоуязвимым драйвером.

9 лайков
#3

В видео от Баранцева, он часто упоминает, что логику для тестов нужно разделять, для этого надо использовать хелперы (помощников), в данном варианте это одно и тоже?

1 лайк
#4

Не могу сказать наверняка, не будучи уверенным в том, о каком видео идет речь. :wink: Но мне кажется, что там была другая идея. В общем случае, тестовая логика - это часть написанного вами DSL, представленного в виде методов PageObjects. Эти методы по дефолту сложно будет связать со статическим контекстом, т.к. там используется чистое наследование с цепочечным вызовом.

Говоря о хэлперах, представьте модули, облегчающие вам жизнь в процессе автоматизации: DateTimeUtils, CurrencyUtils, EmailUtils, StringUtils, ReflectionUtils, PropertiesUtils, XMLUtils, DataProviderUtils, ReportUtils и т.п. Все те вещи, которые фактически могут быть использованы в разных частях приложения, и технически не требуют создания дополнительных сущностей. Оборачивая сырые API каких-нибудь готовых библиотек, и формируя своеобразный single public entry point, вы облегчаете себе разработку как фреймворка в целом, так и доменной части.

1 лайк
#5

static определяется на этапе компиляции, поэтому в коде ты всегда смело можешь к ним обращаться, и тебе не требуется создавать экземпляр класса. тебе нужно понять как выполняется код в java

#6

Да я понимаю, просто мне всегда казалось что использовать везде статик плохо. Например, мне нужно использовать аннотации @BeforeClass и @AfterClass, а методы связанные с ними обязывает сделать все вокруг статик (и сами методы и все что в них). И пока я не совсем понимаю как в дальнейшем это отразится на работе Framework.

Page Object Pattern [пример написания своего фреймворка]
#7

канешно плохо, все зависит от задачи где то тебе нужна динамика, где то статика

#8

Мувайтесь на TestNG :wink:

#9

На него можно без “потерь перейти”? Или в коде нужно будет много чего поменять?

#10

Кроме вас на этот вопрос никто не ответит. Минимум нужно перебить импорты.

1 лайк
#11

Я конечно не знаю на сколько большой и мудреный Вы задумываете фреймворк тестирования, но JUnit обычно хватает с головой. И это совсем не повод муваться на TestNG. JUnit взят за основной фреймворк на многих проектах. И лишь иногда, когда обстоятельства выше нас… приходится муваться на TestNG.

а методы связанные с ними обязывает сделать все вокруг статик (и сами методы и все что в них).

В Java не запрещается в static методах создавать экземпляры классов и вызывать соответствующие методы.