Массовые увольнения в IT

Ну да, ведь мир ограничен масквой

Революция или эволюция Page Object Model?

Позитивных сторон описывать не буду. В любом фреймворке есть смысл, если он упрощает написание тестов. При этом условия применения фреймворков разные, и то, что подходить в одних условиях, совершенно не подходит в иных. Опишу лишь то, что мне не понравилось. Сразу оговорюсь, что автоматизировать и поддерживать приходиться тесты, которые гоняются на множестве однотипных, но немного разных сайтах с разной локализацией которые (иногда) пишутся разными командами разработчиков. И да — разработка идет паралелльно с автоматизацией.
Первое: IMHO параметризируемые элементы в том виде, как они описаны в статье — шаг назад в плане разделения UI слоя от логики страницы. Описанный пример хорош только при определенном построении нелокализуемых приложений. При изменении юзер-интерфейса и/или структуры DOM придется не только менять локаторы, но и бегать по методам в поисках строк типа «Сохранить» если девелоперы решили ее вдруг переделать с button на div. Рефакторинг тут мало поможет. Плюс при наборе кода тестов никакого intellisense-a и надо очень внимательно следить за тем, чтобы не ошибиться в названии кнопки и не напечатать при очередном использовании «Сreate» вместо «Create» (это не ошибка и слова здесь разные). Так что как по мне удобнее потратить лишних 2 минуты на копиаст элементов, но зато саппорт кода и использование этих классов будет в разы удобнее.
Второе: Интерфейсы вместо классов для множественного наследования — тоже не лучший вариант. Я, например, предпочитаю композицию, которая в том числе повысит читаемость тестов и избавит от проблем с одинаковыми именами методов в интерфейсах. А дефолтую имплементацию в интерфейсах оставить для того, для чего они, собственно, и предназначены — обеспечения обратной совместимости библиотек. К примеру, в случае с композицией на гитхабе (у него если линка Issues как в хеадере, так и на странице с проектом):

projectPage.header().openIssues()
projectPage.repoNavigator().openIssues()

В подходе с наследованием в джаве придется уже по-разному именовать методы, что уже неудобно и налагает определенные ограничения когда тесты автоматизирует не 1 человек, а команда. Либо делать как в статье — подключать Header через дополнительный «служебный» интерфейс WithHeader. Но зачем мне еще +1 класс вместо одной строки кода? К тому же страница «состоит из» Header-а, а не «является» WithHeader-ом. (А описанное в начале статьи дублирование селектора для полей типа Header решается просто размещением дефолтного селектора на классе Header)

И еще одно замечание к пункту «При описании стандартных PageObject используются интерфейсы вместо классов.» PageObject — это НЕ набор описаний UI элементов через FindBy. FindBy — это все к шаблну PageFactory. PageObject — это подход к написанию классов таким образом, чтобы его паблик методы описывали то, ЧТО делается на страничке (сервиса, которые предоставляет страница)ь и никаким образом не раскрывали внутренностей реализации (КАК это делается). PageObject можно сделать вообще на «голом» webDriver:
PageObject без PageFactory:

class  MyPage extends BasePage{
  public void login(Credentials creds) {
    wd.findElement(By.name('user')).sendKeys(creds.user);
    ...
  }
} 

PageFactory без PageObject:

class  MyPage extends BasePage{
  @FindBy(css='.name')
  WebElement user;

  public WebElement getUser() { return user;}
} 

Кому интересно, здесь Саймон описывает разницу (смотреть с 17:00): youtu.be/y1pSkqIJvAw?t=1021

Как написание кода с помощью машинного обучения всё (не)изменит

Ну вот тут как раз ЖПТ и рулит. Так как Ваш запрос о select table size уже изначачально может привести к неправильному результату. А плюс ЖПТ в том, что ему можно задать вопрос человеческим языком, а не языком гугла (правильно сформулировав, учитывая доменную область). К тому же Вы ведь хотели узнать, отчего база распухла, а не размеры таблиц? Скрин прикрепить не могу, но ЖПТ на Ваш же вопрос "что там занимает место в БД, отчего это она распухла" выдал:

"В базе данных может занимать место множество различных объектов, таких как таблицы, индексы, представления, процедуры и триггеры. Размер каждого объекта зависит от количества данных, которые он содержит, а также от способа, которым они хранятся в базе данных.Вот несколько возможных причин того, что может занимать много места в базе данных: .... " И далее список из 6 пунктов, из которых размер таблицы хоть и первый но не единственный.
(Следующий вопрос будет (в зависимости от уже вашего контекта), например: "как узнать размеры таблиц?", "а как индексов?")
А вот подобный запрос в гугле может разве что выдать ссылку на эту страницу.

Несколько слов о сабвуферах и том, почему они подойдут почти всем

Счетчик людей, случайно попавших на статью