Наблюдения о поиске сениор позиции в SFBA осень 2018

[nyekimov]

Может быть, потому что спеки и тесты Это разные вещи?

Вот смотри, есть модуль который... Ну, скажем, возводит целое в квадрат. Туда пихаешь 2, получаешь 4. Пихаешь 12, получаешь 144.

Теперь вопрос, какие тесты могут стать "спекой"?

Это тенденция, в принципе для такого простого случая огурец как раз подходит. Будет примерно так, возможно что то упустил но принцип надеюсь понятен

Feature: Math module
As a developer, I want an API module to perform basic math calculations

Scenario: Square of 2 integers
When I pass 6 into Square function
Then I shuold get back 36

Scenario: Square of 0th
When I pass 0 into Square function
Then I shuold get back 0

Scenario: Square of very large numbers
When I pass 46341 into Square function
Then I shuold get back an exception with text "whatever"

Scenario: Square of negatives
When I pass -2 into Square function
Then I shuold get back 4

Scenario: Square of very large negative numbers
When I pass -46341 into Square function
Then I shuold get back an exception with text "whatever"

То есть практически готовая спека для функции. Сразу скажу, у нас так не делаются, огурцы мы используем для unit & integration тестов, считаю что TDD в нашем случае не эффективно. Но возможно, в принципе.

я расскажу как у меня в прошлом проекте было:
в описании фичи есть сцылка на спек, спек - это обычно формула.
Тест пишет аналист, имплементирует тест второй девелопер.
Он же сверяет спек с имплементацией бизнес-логики первого девелопера. Фактически попутно делая код-ревью.
Затем фиксит баги вместе с первым девелопером по результатам ревью и огурцового теста.
Огурцовый тест вливает в тест-фреймворк "навсегда". т.е выполняется в дженкинс при каждом новом коммите кода.
Пока всё зелёное не будет, релизить неззя.
Таким фрейворком поймано 100500 багов и прочих попутных косяков абсолютно без участия людей.

Если имплементриует тест второй девелопер, то без людей не обошлось.
То что тесты выполняются Дженкинсом при любом пул риквесте, в 2018 по моему мнению это маст хэв, но к сожалению не все разделяют эту идею.
Мне нравится ваш подход, но не очевидно, вот скажем я новый разработчик, добавил фичу в легаси код и сломал один из тестов, где мне искать спецификацию на класс? Это легко и очевидно или надо 10 людей опросить?

Кстати, сейчас у нас такая фундаментальная проблема стоит, продукт, как полагается, большой и разбит на фичи, на каждой фиче свой продакт овнер, и вот когда добавляется что то к существующей логике, всегда первым делом вопрос -‘как что работало и что меняется. Продакт овнер нередко хочет, чтобы разработчик сказал ему, что меняется, однако разработчик может быть новеньким, может не работал над этой фичей и то что он видит в коде, может быть заимплементировано неправильно, с ошибками. Команда ведет чейнджлист, но читать его не сначала картины не даст.
Мое мнение, продукт должен знать продакт овнер от а до я, ну именно касательно конкретных фич. Однако вот явный минус нежелания команды писать нормальные спецификации и сценарии. Есть отдельные документы на каждую фичу от ux, но все так разрозненно и даже если было б в одном документе, по мне гораздо легче читать тест сценарии.

[Вячеслав Викторович]

Может быть, потому что спеки и тесты Это разные вещи?

Вот смотри, есть модуль который... Ну, скажем, возводит целое в квадрат. Туда пихаешь 2, получаешь 4. Пихаешь 12, получаешь 144.

Теперь вопрос, какие тесты могут стать "спекой"?

Это тенденция, в принципе для такого простого случая огурец как раз подходит. Будет примерно так, возможно что то упустил но принцип надеюсь понятен

Feature: Math module
As a developer, I want an API module to perform basic math calculations

Scenario: Square of 2 integers
When I pass 6 into Square function
Then I shuold get back 36

Scenario: Square of 0th
When I pass 0 into Square function
Then I shuold get back 0

Scenario: Square of very large numbers
When I pass 46341 into Square function
Then I shuold get back an exception with text "whatever"

Scenario: Square of negatives
When I pass -2 into Square function
Then I shuold get back 4

Scenario: Square of very large negative numbers
When I pass -46341 into Square function
Then I shuold get back an exception with text "whatever"

То есть практически готовая спека для функции. Сразу скажу, у нас так не делаются, огурцы мы используем для unit & integration тестов, считаю что TDD в нашем случае не эффективно. Но возможно, в принципе.

я расскажу как у меня в прошлом проекте было:
в описании фичи есть сцылка на спек, спек - это обычно формула.
Тест пишет аналист, имплементирует тест второй девелопер.
Он же сверяет спек с имплементацией бизнес-логики первого девелопера. Фактически попутно делая код-ревью.
Затем фиксит баги вместе с первым девелопером по результатам ревью и огурцового теста.
Огурцовый тест вливает в тест-фреймворк "навсегда". т.е выполняется в дженкинс при каждом новом коммите кода.
Пока всё зелёное не будет, релизить неззя.
Таким фрейворком поймано 100500 багов и прочих попутных косяков абсолютно без участия людей.

Если имплементриует тест второй девелопер, то без людей не обошлось.
То что тесты выполняются Дженкинсом при любом пул риквесте, в 2018 по моему мнению это маст хэв, но к сожалению не все разделяют эту идею.
Мне нравится ваш подход, но не очевидно, вот скажем я новый разработчик, добавил фичу в легаси код и сломал один из тестов, где мне искать спецификацию на класс? Это легко и очевидно или надо 10 людей опросить?

Кстати, сейчас у нас такая фундаментальная проблема стоит, продукт, как полагается, большой и разбит на фичи, на каждой фиче свой продакт овнер, и вот когда добавляется что то к существующей логике, всегда первым делом вопрос -‘как что работало и что меняется. Продакт овнер нередко хочет, чтобы разработчик сказал ему, что меняется, однако разработчик может быть новеньким, может не работал над этой фичей и то что он видит в коде, может быть заимплементировано неправильно, с ошибками. Команда ведет чейнджлист, но читать его не сначала картины не даст.
Мое мнение, продукт должен знать продакт овнер от а до я, ну именно касательно конкретных фич. Однако вот явный минус нежелания команды писать нормальные спецификации и сценарии. Есть отдельные документы на каждую фичу от ux, но все так разрозненно и даже если было б в одном документе, по мне гораздо легче читать тест сценарии.

я имею ввиду, что ПОТОМ, когда готовая система тестирования построена, то люди уже не нужны. система скажет, что после того как Василий спохмела ввернул болт не по резьбе - правое колесо отвалилось и взорвался паровой котёл.
сцылки на спеки в дескрипшене огурцовой фичи надо искать, сами спеки должны быть в VCS, тогда понятно, что, когда и кто изменил.

[Alexander Troyansky]

я ж и говорю, что текста много, а инфы - мало, что приходится читать по диагонали и распарсил не квадрат, а квадратный корень. Объяснение уже предложил: я - тупой и утомился это всё читать, что, конечно, мои проблемы. Однако не один я такой:
https://www.jackkinsella.ie/articles/wh ... er-testing
что не может не наводить на размышления. На демонстрации может показать, как всё красиво работает, но когда доходит до практического применения на бОльших объёмах, то начинаются обломы (даже если "читать легко", но "требует лишних телодвижений, поэтому используем юнит-тесты")

Вы пытаетесь найти Святой Грааль тестирования? Хочу огорчить - его не существует. Есть задачи, есть инструменты. Для одних подходят одни, для других - другие. Именно поэтому в реальности мы используем и огурцы, и обычные юнит тесты, и кучу мануальных сценариев описанных в TFS, и exploratory тестирование. Что позволяет решать задачу эффективно, то и используем. По поводу ссылки - разбирать лень, большая часть жалоб либо специфична для Руби, либо нытье с точки зрения адепта BDD, который мы как я уже говорил не практикуем. Для нас огурцы это удобный наглядный инструмент для unit & integration тестов, позволяющий разгрузить девелоперов помидоров и перепоручить часть задач тестерам (которые пишут сценарии для интеграционных тестов) и джуниорам которые их заполняют.

Ну как же... Грааль уже придумали. Не понятно, как вот эта простыня, которая, судя по многоразовому использованию "shuold", однозначно заставляет создателя этого огуречного салата использовать копипасту:

Feature: Math module
As a developer, I want an API module to perform basic math calculations

Scenario: Square of 2 integers
When I pass 6 into Square function
Then I shuold get back 36

Scenario: Square of 0th
When I pass 0 into Square function
Then I shuold get back 0

Scenario: Square of very large numbers
When I pass 46341 into Square function
Then I shuold get back an exception with text "whatever"

Scenario: Square of negatives
When I pass -2 into Square function
Then I shuold get back 4

Scenario: Square of very large negative numbers
When I pass -46341 into Square function
Then I shuold get back an exception with text "whatever"

может быть лучше более компактной и читабельной:

assert power(6) == 36
assert power(0) == 0
assert power(46341) # Achtung!
assert power(-2) == 4
assert power(-46341) # Achtung!

Ну это банально для такой строго детерминированной функции. А как этот салат из огурцов будет выглядеть для "спектестов", которые требуют нетривиальных предварительных конфигураций? И что будет с этой "спецификацией", когда на выходе надо проверять, ну например, что-нить более сложное, типа следующей ожидаемой ошибки:

Rule ABC has been violated at page 2, line 6, pos 10

А в следующем релизе (поменялись структура предложения, идентификатор правила и позиции ошибки):

The rule ABC-XY has been violated at page 2, line 7, pos 10

Причём это XY теперь может принимать какие-то разные значения в зависимости от контекста теста. Какие ж будут усилия затрачены, чтобы многостраничный салат из огурцов не протух?

[Alexander Troyansky]

я имею ввиду, что ПОТОМ, когда готовая система тестирования построена, то люди уже не нужны. система скажет, что после того как Василий спохмела ввернул болт не по резьбе - правое колесо отвалилось и взорвался паровой котёл.
сцылки на спеки в дескрипшене огурцовой фичи надо искать, сами спеки должны быть в VCS, тогда понятно, что, когда и кто изменил.

Это хорошо, когда можно играть в детский сад с детерминированными формулами, а у в взрослых людей постоянно что-то меняется. Ну реально так бывает чтобы система тестирования была "готова", так что люди уже не нужны?

[Вячеслав Викторович]

я имею ввиду, что ПОТОМ, когда готовая система тестирования построена, то люди уже не нужны. система скажет, что после того как Василий спохмела ввернул болт не по резьбе - правое колесо отвалилось и взорвался паровой котёл.
сцылки на спеки в дескрипшене огурцовой фичи надо искать, сами спеки должны быть в VCS, тогда понятно, что, когда и кто изменил.

Это хорошо, когда можно играть в детский сад с детерминированными формулами, а у в взрослых людей постоянно что-то меняется. Ну реально так бывает чтобы система тестирования была "готова", так что люди уже не нужны?

Ну вообще-то никто не говорил, что она не меняется. Если меняется бизнес-логика, то естественно должны быть изменены и соответствующие тесты. Довольно часто, вследствии побочных эффектов, тесты валятся и в других частях системы. Если проведён технический рефакторинг - всё тоже самое.
Кто закоммитил код и поломал тесты, тот и чинит или код откатывают.
Собственно принятые жесткие правила в команде и позволяют предсказуемую систему строить. В этом и вся прелесть, что после каждого коммита сразу видно, что обвалилось.
Я описываю свой личный 2-х годовой опыт в команде порядкя 30 человек.
Вы вот про детский сад пишете, ну расскажите как у вас.
CI/CD как я понял вы не используете, огурцовые тесты тоже. А как тогда?
ЗЫ
что такое "детерминированные формулы"?

[Alexander Troyansky]

я имею ввиду, что ПОТОМ, когда готовая система тестирования построена, то люди уже не нужны. система скажет, что после того как Василий спохмела ввернул болт не по резьбе - правое колесо отвалилось и взорвался паровой котёл.
сцылки на спеки в дескрипшене огурцовой фичи надо искать, сами спеки должны быть в VCS, тогда понятно, что, когда и кто изменил.

Это хорошо, когда можно играть в детский сад с детерминированными формулами, а у в взрослых людей постоянно что-то меняется. Ну реально так бывает чтобы система тестирования была "готова", так что люди уже не нужны?

Ну вообще-то никто не говорил, что она не меняется. Если меняется бизнес-логика, то естественно должны быть изменены и соответствующие тесты. Довольно часто, вследствии побочных эффектов, тесты валятся и в других частях системы. Если проведён технический рефакторинг - всё тоже самое.
Кто закоммитил код и поломал тесты, тот и чинит или код откатывают.
Собственно принятые жесткие правила в команде и позволяют предсказуемую систему строить. В этом и вся прелесть, что после каждого коммита сразу видно, что обвалилось.
Я описываю свой личный 2-х годовой опыт в команде порядкя 30 человек.
Вы вот про детский сад пишете, ну расскажите как у вас.
CI/CD как я понял вы не используете, огурцовые тесты тоже. А как тогда?

CI/CD - используем, да. Огурцы - нет. Про то, как у нас бывает, наверное, лучше не рассказывать "после каждого коммита, всё было видно" работает до определённого предела. Если объём тестирования сильно большой, то его как бы в CI/CD не включают. Впрочем за 2 года до таких проблем можно и не успеть добраться.

ЗЫ
что такое "детерминированные формулы"?

Детерминированные функции каждый раз возвращают один и тот же результат, если предоставлять им один и тот же набор входных данных.

[Вячеслав Викторович]

я имею ввиду, что ПОТОМ, когда готовая система тестирования построена, то люди уже не нужны. система скажет, что после того как Василий спохмела ввернул болт не по резьбе - правое колесо отвалилось и взорвался паровой котёл.
сцылки на спеки в дескрипшене огурцовой фичи надо искать, сами спеки должны быть в VCS, тогда понятно, что, когда и кто изменил.

Это хорошо, когда можно играть в детский сад с детерминированными формулами, а у в взрослых людей постоянно что-то меняется. Ну реально так бывает чтобы система тестирования была "готова", так что люди уже не нужны?

Ну вообще-то никто не говорил, что она не меняется. Если меняется бизнес-логика, то естественно должны быть изменены и соответствующие тесты. Довольно часто, вследствии побочных эффектов, тесты валятся и в других частях системы. Если проведён технический рефакторинг - всё тоже самое.
Кто закоммитил код и поломал тесты, тот и чинит или код откатывают.
Собственно принятые жесткие правила в команде и позволяют предсказуемую систему строить. В этом и вся прелесть, что после каждого коммита сразу видно, что обвалилось.
Я описываю свой личный 2-х годовой опыт в команде порядкя 30 человек.
Вы вот про детский сад пишете, ну расскажите как у вас.
CI/CD как я понял вы не используете, огурцовые тесты тоже. А как тогда?

CI/CD - используем, да. Огурцы - нет. Про то, как у нас бывает, наверное, лучше не рассказывать "после каждого коммита, всё было видно" работает до определённого предела. Если объём тестирования сильно большой, то его как бы в CI/CD не включают. Впрочем за 2 года до таких проблем можно и не успеть добраться.

ЗЫ
что такое "детерминированные формулы"?

Детерминированные функции каждый раз возвращают один и тот же результат, если предоставлять им один и тот же набор входных данных.

О! А у вас какие формулы, недетерминированые?
У нас вообще то этот метод использовался:
https://en.wikipedia.org/wiki/Monte_Carlo_method
А у вас?

[Вячеслав Викторович]

Всё таки я не понил, как у взрослых пацанов всё работает? ПОнял только, что всё очень сложно и мне всё равно не понять.

[Alexander Troyansky]

Всё таки я не понил, как у взрослых пацанов всё работает? ПОнял только, что всё очень сложно и мне всё равно не понять.

В вашем детском саду всё тестирование проводится исключительно в пределах юнит-тестов, когда "после каждого коммита всё видно"? У вас чё реально системные тесты, UI, проверка безопасности, стресс, производительности запускаются после каждого коммита? Обязательно расскажите о своём успехе Нетфликсу и Мордокниге, а то у них доходит до канарейчных методов тестирования на ограниченном количестве пользователей.

[IvanGrozniy]

Сам я с восточного побережья и хочу спросить знающих из западного побережья. Вроде бы у вас там пожар большой был и все кашляли от дыма. В связи с этим район SF уже "отличился" и попал в списки самых загрязненных городов США, если судить по экологическому индексу чистоты воздуха AQI. Неужели даже это на рост цен фанерных домиков не влияет?

[Krys-Krys]

Сам я с восточного побережья и хочу спросить знающих из западного побережья. Вроде бы у вас там пожар большой был и все кашляли от дыма. В связи с этим район SF уже "отличился" и попал в списки самых загрязненных городов США, если судить по экологическому индексу чистоты воздуха AQI. Неужели даже это на рост цен фанерных домиков не влияет?

На рост цен влият то сколько народ $$$ зарабатывает, а не очень чистый воздух 2 недели подряд раз в Н лет - нет.

[Бубновый Валет]

Сам я с восточного побережья и хочу спросить знающих из западного побережья. Вроде бы у вас там пожар большой был и все кашляли от дыма. В связи с этим район SF уже "отличился" и попал в списки самых загрязненных городов США, если судить по экологическому индексу чистоты воздуха AQI. Неужели даже это на рост цен фанерных домиков не влияет?

Уже все прошло. Сейчас дожди тем более. Воздух чистый. Бей Эрии вообще пофиг на пожары, их тут не было. Другой климат немного. Пожары были в 100 милях, а это довольно далеко. И то, что там происходит - вообще всем пофиг. А домики, кстати, сами по себе ничего не стоят. Поэтому хоть фанера, хоть пенопласт. Цена земли под ними дорогая - китайцы из моей конторы грешат на коррумпированных китайцев, которые сюда приезжают и все скупают.

[IvanGrozniy]

Сам я с восточного побережья и хочу спросить знающих из западного побережья. Вроде бы у вас там пожар большой был и все кашляли от дыма. В связи с этим район SF уже "отличился" и попал в списки самых загрязненных городов США, если судить по экологическому индексу чистоты воздуха AQI. Неужели даже это на рост цен фанерных домиков не влияет?

Уже все прошло. Сейчас дожди тем более. Воздух чистый. Бей Эрии вообще пофиг на пожары, их тут не было. Другой климат немного. Пожары были в 100 милях, а это довольно далеко. И то, что там происходит - вообще всем пофиг. А домики, кстати, сами по себе ничего не стоят. Поэтому хоть фанера, хоть пенопласт. Цена земли под ними дорогая - китайцы из моей конторы грешат на коррумпированных китайцев, которые сюда приезжают и все скупают.

Ну пожар в 100 милях от вашго региона, а народ дымом у вас дышит. Я об этом. Есть знакомые бегуны-спортсмены с этого региона. Никто почти не бегал на улице. Кому невтерпеж было, те в распираторах в природных парках бегали. Зачем такое удовольствие где фанерные хибары по мильону стоят Пусть хоть на две недели в году (теперь почти ежегодно так будет из-за глобального потепления), но все же - распираторные заболевания провоцирует даже такой короткий срок.

[M. Ridcully]

Ну пожар в 100 милях от вашго региона, а народ дымом у вас дышит. Я об этом. Есть знакомые бегуны-спортсмены с этого региона. Никто почти не бегал на улице. Кому невтерпеж было, те в распираторах в природных парках бегали. Зачем такое удовольствие где фанерные хибары по мильону стоят Пусть хоть на две недели в году (теперь почти ежегодно так будет из-за глобального потепления), но все же - распираторные заболевания провоцирует даже такой короткий срок.

Дым был очень неприятным, да, но каким боком это на цене домов должно сказываться? Это разовое событие было. Единственный раз такое за 10+ лет что я тут. Я уверен, что такие же пожары могут и у вас быть (не дай бог, конечно), если только вы не в Антерктиде, где гореть нечему.

[Easbayguy]

Ну пожар в 100 милях от вашго региона, а народ дымом у вас дышит. Я об этом. Есть знакомые бегуны-спортсмены с этого региона. Никто почти не бегал на улице. Кому невтерпеж было, те в распираторах в природных парках бегали. Зачем такое удовольствие где фанерные хибары по мильону стоят Пусть хоть на две недели в году (теперь почти ежегодно так будет из-за глобального потепления), но все же - распираторные заболевания провоцирует даже такой короткий срок.

Дым был очень неприятным, да, но каким боком это на цене домов должно сказываться? Это разовое событие было. Единственный раз такое за 10+ лет что я тут. Я уверен, что такие же пожары могут и у вас быть (не дай бог, конечно), если только вы не в Антерктиде, где гореть нечему.

Вы прям про Соному забыли год назад? TUBBS FIRE - (Sonoma County), October 2017
CARR FIRE (Shasta County, Trinity County), July 2018
Ну или VALLEY FIRE (Lake, Napa & Sonoma County), September 2015

Воняло тоже не по детски.