Даша, это известное различие между британским и американским вариантами. В окончаниях где в британском -our в американском пишется просто -or.

В американском flavor , в британском flavour , например.

Википедия en написана американским.

https://en.wikipedia.org/wiki/Behavior-driven_development

спасибо

я не про это) ты без v написал, я думала у них так же.

Ну это опечатка была, спасибо, поправил.

Мне кажется, у Баранцева питон для тестировщиков более связно дан.

а что за отдельный такой питон для тестировщиков?

это курс отдельный, а не питон.

и что там такого особенного рассказывают?

Я не раз что-то пытался людям рассказывать в профессиональном плане, и слушал кучу разных лекций. Час-полтора это "обзорная экскурсия". Тебя гоняют по разным темам и ты узнаёшь что такое вот есть, но не так чтоб сильно учишься с ним работать.  Если подходить к вопросу более добросовестно, то надо
- выбрать один подход, Pytest везде или xUnit везде.
- объяснить почему он выбран
- Robot выкинуть (хотя я неплохо к нему отношусь, но)
- troubleshooting в Linux не только лишь для всех тоже , сделайте по нему отдельный мини-курс для тех кому он нужен.

Какого? По питону?)

вот кстати Баранцев вообще не объяснял, почему именно pytest. Сказал, что в нем больше всяких фич, чем в unittest, на котором был самый первый тест в курсе.

да

я бы вот по настройке дженкинса с 0 прошел что-нибудь. Как запустить свои питонячьи тесты и все такое. Есть какой-то туториал годный?

Ну "больше всяких фич" это уже минимальное объяснение :)

Это четыре отдельных темы.
1) Запуск Python проверок из командной строки. Если ты используешь Pytest, Pyunit или что там ещё есть, это должно быть в доках.
2) Какое окружение нужно твоим проверкам
3) Как втулить в это окружение Дженкинс
4) Как настроить джобу.

Когда я работал с автоматизаторами, в том числе имея собственноручно написанный инструмент реализоваываший на нашем приложении monkey testing, мне автоматизаторы говорили что достаточно иметь запуск из командной строки чтобы девопсы-дноопсы потом прикрутили это к дженкинсу. В реальности это оказалось не так просто, но они прикрутили.

Туториалов на Ютубе на эту тему есть, сам не занимался поскольку не было прямой практической необходимости — окружениями управляли дноопсы, а у меня так или иначе не было прав там что-то настраивать.

я бы начал с того, есть лив компании девопсы, которые могут быстро пнуть в нужное направление
ежели своими силами,
<НЗ,  самый ли простой способ, я игрался таким образом со своими ci>
поднять у себя в докере, цепануть к гитхабу с питонячьими тестами,  добавить jenkinsfile (можно их делать и в самом дженкинсе и возможно там есть ui-ные вспомогашки описания шагов, но наш народ рекомендует с кодом хранить) типа
~docker-compose.yml

jenkins:
  image: jenkinsci/blueocean
  ports:
    - 50000:50000
  environment:
   JENKINS_HOME: /jenkins_home
  user: root
  privileged: true
  volumes:
    - ./data_jenkins:/jenkins_home
    - /var/run/docker.sock:/var/run/docker.sock

~JenkinsFile

#!groovy
pipeline {
  agent any
  stages {
   stage('python tests') {
     steps{
       'sh <запуск питонячьих тестов>'
    }
  }
}

и копать оттуда
"цепануть к гитхабу с питонячьими тестами" -  копать в сторону Settings проекта, Deploy keys + Webhooks, при создании джобы тыкнуть General->GitHub project(cо своим урлом)/ Build Triggers -> GitHub hook trigger for
GITScm polling
Pipeline->Pipeline script from scm - выбираешь свою репу (Credentials - это deploy key, приватная часть сохраненная в дженкинсе(ssh -ключи генерить умеете?))
Script Path -Jenkinsfile  - тогда джоба будет триггериться на пуш твоих тестов
И получай песочницу/свою ci
при желании пара дней занимает, заодно мб общее представление  о процессах  даст. Хотя мб вопрос был в другом, нз

чем точнее формулируется вопрос, тем понятнее первый шаг

девопсы у нас есть, у нас и дженкинс они настраивают, но там совсем адище для меня, все в амазоне крутится

Мне бы простенькие селениум тесты начать запускать)