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

[ystar]

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

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

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

[ystar]

Почему то никто не упомянул, что тесты могут ( и скорее должны) быть спекой.

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

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

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

Тот самый тест:
Describe(“test power module”)
Context(“square operation”)
Context(“when sending 2”)
It(“should be equal to 4”)
Expect(bla(2)) == 4

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

Самое сложное, это прийти к такому формату, чтобы было приятно читать.

Уж извините, но это полная херня а не тест получится, когда этого всего будет 10к+ строк

почитайте про rspec и прочие аналоги.

Я говоря о формате, это и имел ввиду, что надо как то написать так, чтобы было и не слишком коротко и не слишком длинно. Но вообще да, рспек и его аналоги имеют больше доп инфы, но зато она дает лучше картину, что происходит вообще.

я очень хорошо все это знаю, и вижу как это не работает на больших проектах.

[major Major Major Major]

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

Очень часто, особенно когда тестируется API, каждый вызов это достаточно простой случай. Не всегда, не во всех проектах, но очень часто. Мы же не пытаемся вывести общую теорию всего? В программировании это вообще редкость. А что касается большого числа то квадрат 46341 это переполнение int32. В принципе, можно добавить 46340 как граничный случай с другой стороны, но я уже сказал что не пытался написать за 2 минуты полный тест. В реальности текст ошибки как раз бы и написал причину.

[ystar]

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

Очень часто, особенно когда тестируется API, каждый вызов это достаточно простой случай. Не всегда, не во всех проектах, но очень часто. Мы же не пытаемся вывести общую теорию всего? В программировании это вообще редкость. А что касается большого числа то квадрат 46341 это переполнение int32. В принципе, можно добавить 46340 как граничный случай с другой стороны, но я уже сказал что не пытался написать за 2 минуты полный тест. В реальности текст ошибки как раз бы и написал причину.

BDD в API - это вообще индюком надо быть, чтобы так делать, уж простите

[nyekimov]

я очень хорошо все это знаю, и вижу как это не работает на больших проектах.

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

[major Major Major Major]

BDD в API - это вообще индюком надо быть, чтобы так делать, уж простите

С чего бы это? Вы еще скажите, что спеки для API только индюки пишут.

[АццкоМото]

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

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

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

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

[Kirpidonych]

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

[АццкоМото]

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

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

[Kirpidonych]

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

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

[Kirpidonych]

Огурец также позволяет понимать что у вас за тесты и что они делают тогда когда они живут уже 100 лет и никто не помнит что мы вообще там тестируем.

[АццкоМото]

но вот в ФБР целый отдел есть называется АНБ.

Ояе. Если вы считаете, что АНБ это отдел ФБР, то самая сложная проблема, которую с вами можно обсудить, это куда лучше лепить козявки.

[Kirpidonych]

а потом - это красиво %)

[АццкоМото]

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

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

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

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

[Kirpidonych]

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

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

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

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

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