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

[Kirpidonych]

а про года, это ты не смотри. Тут как получается. Пользуется то, что позоволяет быстро собрать что-то что может показывать такущий статус дел на проекте. Сколько ошибок, где они, как долго они присутствуют, и так далее. И что позоволяет быстро ходить в курс дел новым в команде. И текущим сократить время на понимание где у них проблемы.

[Alexander Troyansky]

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

Вот смотри, есть модуль который... Ну, скажем, возводит целое в квадрат. Туда пихаешь 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 в нашем случае не эффективно. Но возможно, в принципе.

какаятотрудночитаемаяневедомаяебаннаяхерня... да ещё и корень из -2 будет 4. Или ошибка илия - тупой и утомился пока это пытался понять (квадрат, а не квадратный корень)?. Таким образом решается вопрос связи между спеками и тестами?

[АццкоМото]

В любом случае, не слишком ли дофига текста для простейшей функции?

есть разные подходы , кто-то делает вот такие функции, кто-то пишет большие сценарии. Зависит от много чего. Есть лючшие практики, но всегда применять здравый смысл, как всегда в общем

Да пойми, если для функции square() нужно огурцом махать на экран текста и потом ещё оговариваться, что это только пример, а так-то нужно ещё дописать, это не работает в реале.

В принципе, нечто очень подобное огурцу моя команда разработала в 2001-2003 годах. Но мы блдж в 2018!!!

чем махать решает команда, если они решили в им это нужно, грех мешать взрослым разумным людям.

Да когда команда решала?? А если и решала, почему это вдруг сразу правильно?

[nyekimov]

В любом случае, не слишком ли дофига текста для простейшей функции?

есть разные подходы , кто-то делает вот такие функции, кто-то пишет большие сценарии. Зависит от много чего. Есть лючшие практики, но всегда применять здравый смысл, как всегда в общем

Да пойми, если для функции square() нужно огурцом махать на экран текста и потом ещё оговариваться, что это только пример, а так-то нужно ещё дописать, это не работает в реале.

В принципе, нечто очень подобное огурцу моя команда разработала в 2001-2003 годах. Но мы блдж в 2018!!!

чем махать решает команда, если они решили в им это нужно, грех мешать взрослым разумным людям.

Да когда команда решала?? А если и решала, почему это вдруг сразу правильно?

Что и у тебя команда не может выбирать, как и на чем ей работать? О_о

[major Major Major Major]

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

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

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

Это не совсем тесты. Это тесты с требованиями в одной кастрюле

Ну так я и ответил на твой вопрос

[major Major Major Major]

какаятотрудночитаемаяневедомаяебаннаяхерня... да ещё и корень из -2 будет 4. Или ошибка илия - тупой и утомился пока это пытался понять (квадрат, а не квадратный корень)?. Таким образом решается вопрос связи между спеками и тестами?

Ну если ты не знаешь разницы между square и square root то случай совсем безнадежен и никакие огурцы уже не помогут, только assembler, только хардков

А читается легко, причем в VS оно еще все подсвечено (ключевые слова, параметры), и линкуется с методами. То есть в данном случае имплементация будет в 3 метода - один вызов функции с параметром (число), второй сравение результата с числом и третий сравнение ошибки с текстом. Из этих трех методов собираются сценарии. То есть если мне надо будет добавить тест на другое граничное число, кода писать будет не надо - достаточно набрать сценарий в огурце и он слинкуется с уже существующими методами. Это очень удобно когда требуются похожие действия на различные данные - к примеру, у нас есть некий кусок кода который индексирует файлы и позволяет искать текст. На вход тестов подаются различные файли и параметры индексирования типа игнорирования регистра, в when идет поисковая фраза, в then количество найденых слов. Таких тестов реально много, но самого кода с гулькин нос, три метода. При этом читать и добавлять новые сценарии при необходимости можно доверить даже не программисту, а тестеру после нахождения и исправления багов.

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

Как я уже сказал, TDD (BDD) мы не практикуем но инструментами пользуемся когда это полезно.

[Kirpidonych]

как-то так

[Alexander Troyansky]

какаятотрудночитаемаяневедомаяебаннаяхерня... да ещё и корень из -2 будет 4. Или ошибка илия - тупой и утомился пока это пытался понять (квадрат, а не квадратный корень)?. Таким образом решается вопрос связи между спеками и тестами?

Ну если ты не знаешь разницы между square и square root то случай совсем безнадежен и никакие огурцы уже не помогут...

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

[ystar]

2 - а почему вдруг 46341 большим числом стало? мне вот из теста не понятно. какая то у вас херовая функция, раз 46к для неё большое число.

Т.е. даже тут догадаться вы не смогли? Ну типа взять калькулятор, возвести 46341 в квадрат и прикинуть член к носу, что напоминает результат?

И это говорит человек, который про докер узнал в конце 2018 года.

[nyekimov]

какаятотрудночитаемаяневедомаяебаннаяхерня... да ещё и корень из -2 будет 4. Или ошибка илия - тупой и утомился пока это пытался понять (квадрат, а не квадратный корень)?. Таким образом решается вопрос связи между спеками и тестами?

Ну если ты не знаешь разницы между square и square root то случай совсем безнадежен и никакие огурцы уже не помогут...

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

Да просто на больших объемах все сложно. Сложно найти достаточное количество хороших мыслящих в одном направлении разработчиков. Не писать тесты со спецификацией, тогда нужно отдельно тесты и отдельно спецификация и две вещи параллельно вести тоже будет нудно. И большинство просто не будут знать, где эт спецификация, кроме того, кто ее пишет.
Хотя да, если иметь хорошую команду, то главное договориться на чем то и следовать, это важнее самой методики, главное чтобы все были довольны и имели желание соблюдать договоренности.

[major Major Major Major]

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

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

[АццкоМото]

2 - а почему вдруг 46341 большим числом стало? мне вот из теста не понятно. какая то у вас херовая функция, раз 46к для неё большое число.

Т.е. даже тут догадаться вы не смогли? Ну типа взять калькулятор, возвести 46341 в квадрат и прикинуть член к носу, что напоминает результат?

И это говорит человек, который про докер узнал в конце 2018 года.

Ну, во-первых он у меня установлен пару лет как. Во-вторых, как мобильщику он мне в пуп не упёрся 99.9% времени.

Ну и наконец не надо путать конкретную технологию и computer science 101

[АццкоМото]

Что и у тебя команда не может выбирать, как и на чем ей работать? О_о

А как вообще команда может решить? Голосованием что ли? Да, команда может что-то предложить, но решает-то лид. Он у нас кстати весьма адекватный и либеральный.

[major Major Major Major]

Хотя да, если иметь хорошую команду, то главное договориться на чем то и следовать, это важнее самой методики, главное чтобы все были довольны и имели желание соблюдать договоренности.

Главное это наличие контролера исполнение договоренностей


https://www.youtube.com/watch?time_cont ... gUevFTLhW0

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

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

Вот смотри, есть модуль который... Ну, скажем, возводит целое в квадрат. Туда пихаешь 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 багов и прочих попутных косяков абсолютно без участия людей.