Возможно, я что-то упустил из виду. Но набор зависимостей выглядит больше, чем "необходимый".
Есть подключение jUnit, при этом org.testcontainers:spock, а использование самого Spock не заметил. Да и вряд ли в такой материал его стоило бы добавлять.
Зависимость junit:junit на Maven Central 4.13.2 последней версии, которая была выпущена 3 года назад, потому что артефакт был перемещен: org.junit.jupiter:junit-jupiter-api
Аннотации от lombok наблюдаются, который не упоминается сам, да и не видно особого повода для их применения в такой подаче "отдельный элементов" кода.
Указывать @DirtiesContext, как необходимую аннотацию для тест-класса не самый полезный совет во многих случаях.
Возможно, материал может дать какие-то стартовые подсказки совсем новичкам, но без попытки все самостоятельно "прогуглить", может направить куда-то не туда.
Не совсем так. Коммит в Git - это полный снимок (snapshot) всей рабочей директории в определенный момент времени, просто внутреннее хранилище работает по принципу адресации по содержимому, что позволяет использовать ранее созданные объекты, пока не поменялось их содержимое.
Изначально Git сохраняет не отдельные измененные строки в файле, а содержимое файла полностью. При этом даже не в момент фиксации нового коммита, а при добавлении файла в индекс.
Хотя в дальнейшем для оптимизации объема данных может "сжать" версии файлов в один pack, который формируется по принципу наиболее актуальный снимок + дельты для формирования предыдущих снимков.
Аутсорс может и не так сильно отличается от "инхаус". Потому что здесь происходит продажа работ/услуг. Только вот в последнее время в сфере IT все дружно перешли на аутстаффинг, когда продают не услуги, а просто человеко-часы. И вопрос, на сколько такая компания прям уж IT остается. Когда предлагается услуга, то тут возникает необходимость думать об экспертизах, качестве, чтобы сделать свою услугу более конкурентной на рынке и маржинальной для себя. А когда происходит сугубо торговля человеко-часами, то тут одна "оптимизация": закупить подешевле, продать подороже и побольше. Смена проекта, конечно, возможна. Только сперва "сотрудник" сам себя должен продать новому заказчику через полноценные собеседования. Много аутстафф-компаний давно не заморачиваются и работают сугубо из подхода: когда будет заказчик, который вас купит, тогда будет вам предложение о трудоустройстве. И кидают заказчикам резюме, которые даже никак не проверяются на соответствие реальности.
Формат статьи, про "заботливый аутсорс", который прям готов давать вам больше, чем на вас же заработает, и "недружелюбный инхаус" позабавил.
А есть опыт использования данного фреймворка именно в BDD подходе, как он описан в начале статьи?
Как-то сам Spock не сильно себя относит к BDD фреймворку, судя по его документации. Сочетание "Behavior Driven Development" увидел там ровно один раз и то в контексте:
"In Behavior Driven Development, customer‑facing features (called stories) are described in a given‑when‑then format. Spock directly supports this style of specification with the given: label:"
Я так понимаю, что эта "поддержка BDD стиля" по сути отражена в последнем примере. Но сомневаюсь, что аналитик или кто-то от бизнеса смогут что-то для себя понять из такого формата, когда из 34 строк ему надо прочитать только 13, 15, 21, 29 и проигнорировать остальные 30.
В чём состоит особенность написания BDD тестов в Spock? Видимо, в том, что можно получить расширенные диагностические сообщения и текстовые отчеты по итогам запуска тестов. Но вот в создании, поддержке и каком-то развитии сложно ожидать чьё-то участие, кроме разработчиков/автотестеров.
Фреймворки, где истории/сценарии отделены от непосредственной реализации этих шагов выглядят более перспективными, чтоб говорить о BDD.
Возможно, я что-то упустил из виду. Но набор зависимостей выглядит больше, чем "необходимый".
Есть подключение jUnit, при этом org.testcontainers:spock, а использование самого Spock не заметил. Да и вряд ли в такой материал его стоило бы добавлять.
Зависимость junit:junit на Maven Central 4.13.2 последней версии, которая была выпущена 3 года назад, потому что артефакт был перемещен: org.junit.jupiter:junit-jupiter-api
Аннотации от lombok наблюдаются, который не упоминается сам, да и не видно особого повода для их применения в такой подаче "отдельный элементов" кода.
Указывать @DirtiesContext, как необходимую аннотацию для тест-класса не самый полезный совет во многих случаях.
Возможно, материал может дать какие-то стартовые подсказки совсем новичкам, но без попытки все самостоятельно "прогуглить", может направить куда-то не туда.
Не совсем так. Коммит в Git - это полный снимок (snapshot) всей рабочей директории в определенный момент времени, просто внутреннее хранилище работает по принципу адресации по содержимому, что позволяет использовать ранее созданные объекты, пока не поменялось их содержимое.
Изначально Git сохраняет не отдельные измененные строки в файле, а содержимое файла полностью. При этом даже не в момент фиксации нового коммита, а при добавлении файла в индекс.
Хотя в дальнейшем для оптимизации объема данных может "сжать" версии файлов в один pack, который формируется по принципу наиболее актуальный снимок + дельты для формирования предыдущих снимков.
Аутсорс может и не так сильно отличается от "инхаус". Потому что здесь происходит продажа работ/услуг.
Только вот в последнее время в сфере IT все дружно перешли на аутстаффинг, когда продают не услуги, а просто человеко-часы.
И вопрос, на сколько такая компания прям уж IT остается.
Когда предлагается услуга, то тут возникает необходимость думать об экспертизах, качестве, чтобы сделать свою услугу более конкурентной на рынке и маржинальной для себя.
А когда происходит сугубо торговля человеко-часами, то тут одна "оптимизация": закупить подешевле, продать подороже и побольше.
Смена проекта, конечно, возможна. Только сперва "сотрудник" сам себя должен продать новому заказчику через полноценные собеседования.
Много аутстафф-компаний давно не заморачиваются и работают сугубо из подхода: когда будет заказчик, который вас купит, тогда будет вам предложение о трудоустройстве. И кидают заказчикам резюме, которые даже никак не проверяются на соответствие реальности.
Формат статьи, про "заботливый аутсорс", который прям готов давать вам больше, чем на вас же заработает, и "недружелюбный инхаус" позабавил.
А есть опыт использования данного фреймворка именно в BDD подходе, как он описан в начале статьи?
Как-то сам Spock не сильно себя относит к BDD фреймворку, судя по его документации.
Сочетание "Behavior Driven Development" увидел там ровно один раз и то в контексте:
"In Behavior Driven Development, customer‑facing features (called stories) are described in a given‑when‑then format. Spock directly supports this style of specification with the given: label:"
Я так понимаю, что эта "поддержка BDD стиля" по сути отражена в последнем примере. Но сомневаюсь, что аналитик или кто-то от бизнеса смогут что-то для себя понять из такого формата, когда из 34 строк ему надо прочитать только 13, 15, 21, 29 и проигнорировать остальные 30.
В чём состоит особенность написания BDD тестов в Spock?Видимо, в том, что можно получить расширенные диагностические сообщения и текстовые отчеты по итогам запуска тестов. Но вот в создании, поддержке и каком-то развитии сложно ожидать чьё-то участие, кроме разработчиков/автотестеров.
Фреймворки, где истории/сценарии отделены от непосредственной реализации этих шагов выглядят более перспективными, чтоб говорить о BDD.