Пишу про тесты не в первый раз, не в последний и даже не в предпоследний. Слишком большая тема:)
Сегодня я хочу поговорить про слова, которыми мы записываем тест. Какие тут могут быть проблемы: лишние слова, длинные слова, сложные слова.
Казалось бы - ерунда. Какая разница, напишем мы где-то одно слово вместо двух.
Не побоюсь прослыть занудой, которая экономит буковки. Слова, которые присутствуют в тесте и при этом не привносят ценность - это лишнее время на чтение и осознание прочитанного. Они создают визуальный шум и сбивают с фокуса.
В каком-то смысле слова - это наш код) Это скрипт, который объясняет человеку, что нужно делать, чтобы что-то проверить.
На нашем проекте примерно 20 000 тестов. Допустим, в каждом тесте всего одно лишнее слово. 20 000 строк кода, которые приносят ноль пользы!
Иногда лишние или более длинные слова используются, потому что это выглядит более наукообразно и солидно. У меня не какие-то там Steps, у меня Input specification. Иногда просто берется шаблон (например, из стандарта) и применяется как есть, без адаптации. Думаю, есть и другие причины (в том числе «не подумали, что так можно»). Но если у вас не супержесткие требования к документации (например, нужно по закону соответствовать определенным стандартам), то, скорее всего, можно договориться с командой и писать тесты в другом стиле. Скорее всего, вы-из-будущего скажете себе-из-настоящего большое спасибо.
Сложные предложения: тут все аналогично.
Когда текст теста состоит из сложносочиненных/сложноподчиненных предложений, наукообразных слов, витиватых формулировок и прочих велеречивых словоречений (с) - мы стреляем себе в ногу. При таких условиях даже чтение простых тестов требует больших усилий, что уж говорить про сложные.
Поэтому я за то, чтобы упрощать все, что можно упростить, и экономить силы для другого. Например, на критическое осмысление теста и само тестирование.
Successful
Вынесу это слово в отдельный пункт, потому что причиняет мне отдельную сильную боль (наряду с табличным форматом тестов, но о нем я напишу когда-нибудь потом).
Не знаю, как это слово просачивается в документацию. Возможно, вайбы Линкедина, рекомендаций по написанию резюме и прочего успешного успеха так сильны, что людям сложно написать «значение поля в базе изменилось» и вместо этого они автоматически пишут «значение поля в базе успешно изменилось». Возможно, люди думают, что без «успешно» формулировки выглядят недостаточно весомыми. В чем разница между «значение изменилось» и «значение успешно изменилось», мне пока никто не смог объяснить (я спрашивала).
Что могу тут сказать:
- «Успешно» в результатах теста это очень неконкретное понятие и не может быть критерием того, пройден тест или нет. В результатах должно быть написано, как конкретно мы понимаем, что (например) поле изменило свое значение - Все тесты проверяют, «успешно» ли (в соответствии с ожиданиями) работает наше ПО. Это подразумевается и так, даже если мы нигде никогда не напишем в тестах слово «успешно»
Немного о личном опыте: иногда у меня получается сократить чужой тест в 2 раза просто за счет упрощения формулировок. Моя команда давно так не пишет, но порой из тьмы веков всплывают древние ископаемые и с ними приходится что-то делать.
Пишу про тесты не в первый раз, не в последний и даже не в предпоследний. Слишком большая тема:)
Сегодня я хочу поговорить про слова, которыми мы записываем тест. Какие тут могут быть проблемы: лишние слова, длинные слова, сложные слова.
Казалось бы - ерунда. Какая разница, напишем мы где-то одно слово вместо двух.
Не побоюсь прослыть занудой, которая экономит буковки. Слова, которые присутствуют в тесте и при этом не привносят ценность - это лишнее время на чтение и осознание прочитанного. Они создают визуальный шум и сбивают с фокуса.
В каком-то смысле слова - это наш код) Это скрипт, который объясняет человеку, что нужно делать, чтобы что-то проверить.
На нашем проекте примерно 20 000 тестов. Допустим, в каждом тесте всего одно лишнее слово. 20 000 строк кода, которые приносят ноль пользы!
Иногда лишние или более длинные слова используются, потому что это выглядит более наукообразно и солидно. У меня не какие-то там Steps, у меня Input specification. Иногда просто берется шаблон (например, из стандарта) и применяется как есть, без адаптации. Думаю, есть и другие причины (в том числе «не подумали, что так можно»). Но если у вас не супержесткие требования к документации (например, нужно по закону соответствовать определенным стандартам), то, скорее всего, можно договориться с командой и писать тесты в другом стиле. Скорее всего, вы-из-будущего скажете себе-из-настоящего большое спасибо.
Сложные предложения: тут все аналогично.
Когда текст теста состоит из сложносочиненных/сложноподчиненных предложений, наукообразных слов, витиватых формулировок и прочих велеречивых словоречений (с) - мы стреляем себе в ногу. При таких условиях даже чтение простых тестов требует больших усилий, что уж говорить про сложные.
Поэтому я за то, чтобы упрощать все, что можно упростить, и экономить силы для другого. Например, на критическое осмысление теста и само тестирование.
Successful
Вынесу это слово в отдельный пункт, потому что причиняет мне отдельную сильную боль (наряду с табличным форматом тестов, но о нем я напишу когда-нибудь потом).
Не знаю, как это слово просачивается в документацию. Возможно, вайбы Линкедина, рекомендаций по написанию резюме и прочего успешного успеха так сильны, что людям сложно написать «значение поля в базе изменилось» и вместо этого они автоматически пишут «значение поля в базе успешно изменилось». Возможно, люди думают, что без «успешно» формулировки выглядят недостаточно весомыми. В чем разница между «значение изменилось» и «значение успешно изменилось», мне пока никто не смог объяснить (я спрашивала).
Что могу тут сказать:
- «Успешно» в результатах теста это очень неконкретное понятие и не может быть критерием того, пройден тест или нет. В результатах должно быть написано, как конкретно мы понимаем, что (например) поле изменило свое значение - Все тесты проверяют, «успешно» ли (в соответствии с ожиданиями) работает наше ПО. Это подразумевается и так, даже если мы нигде никогда не напишем в тестах слово «успешно»
Немного о личном опыте: иногда у меня получается сократить чужой тест в 2 раза просто за счет упрощения формулировок. Моя команда давно так не пишет, но порой из тьмы веков всплывают древние ископаемые и с ними приходится что-то делать.
BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
The administrator of a telegram group, "Suck Channel," was sentenced to six years and six months in prison for seven counts of incitement yesterday. The group also hosted discussions on committing arson, Judge Hui said, including setting roadblocks on fire, hurling petrol bombs at police stations and teaching people to make such weapons. The conversation linked to arson went on for two to three months, Hui said. Avoid compound hashtags that consist of several words. If you have a hashtag like #marketingnewsinusa, split it into smaller hashtags: “#marketing, #news, #usa. Some Telegram Channels content management tips The group’s featured image is of a Pepe frog yelling, often referred to as the “REEEEEEE” meme. Pepe the Frog was created back in 2005 by Matt Furie and has since become an internet symbol for meme culture and “degen” culture.
from us
