Пишу про тесты не в первый раз, не в последний и даже не в предпоследний. Слишком большая тема:)
Сегодня я хочу поговорить про слова, которыми мы записываем тест. Какие тут могут быть проблемы: лишние слова, длинные слова, сложные слова.
Казалось бы - ерунда. Какая разница, напишем мы где-то одно слово вместо двух.
Не побоюсь прослыть занудой, которая экономит буковки. Слова, которые присутствуют в тесте и при этом не привносят ценность - это лишнее время на чтение и осознание прочитанного. Они создают визуальный шум и сбивают с фокуса.
В каком-то смысле слова - это наш код) Это скрипт, который объясняет человеку, что нужно делать, чтобы что-то проверить.
На нашем проекте примерно 20 000 тестов. Допустим, в каждом тесте всего одно лишнее слово. 20 000 строк кода, которые приносят ноль пользы!
Иногда лишние или более длинные слова используются, потому что это выглядит более наукообразно и солидно. У меня не какие-то там Steps, у меня Input specification. Иногда просто берется шаблон (например, из стандарта) и применяется как есть, без адаптации. Думаю, есть и другие причины (в том числе «не подумали, что так можно»). Но если у вас не супержесткие требования к документации (например, нужно по закону соответствовать определенным стандартам), то, скорее всего, можно договориться с командой и писать тесты в другом стиле. Скорее всего, вы-из-будущего скажете себе-из-настоящего большое спасибо.
Сложные предложения: тут все аналогично.
Когда текст теста состоит из сложносочиненных/сложноподчиненных предложений, наукообразных слов, витиватых формулировок и прочих велеречивых словоречений (с) - мы стреляем себе в ногу. При таких условиях даже чтение простых тестов требует больших усилий, что уж говорить про сложные.
Поэтому я за то, чтобы упрощать все, что можно упростить, и экономить силы для другого. Например, на критическое осмысление теста и само тестирование.
Successful
Вынесу это слово в отдельный пункт, потому что причиняет мне отдельную сильную боль (наряду с табличным форматом тестов, но о нем я напишу когда-нибудь потом).
Не знаю, как это слово просачивается в документацию. Возможно, вайбы Линкедина, рекомендаций по написанию резюме и прочего успешного успеха так сильны, что людям сложно написать «значение поля в базе изменилось» и вместо этого они автоматически пишут «значение поля в базе успешно изменилось». Возможно, люди думают, что без «успешно» формулировки выглядят недостаточно весомыми. В чем разница между «значение изменилось» и «значение успешно изменилось», мне пока никто не смог объяснить (я спрашивала).
Что могу тут сказать:
- «Успешно» в результатах теста это очень неконкретное понятие и не может быть критерием того, пройден тест или нет. В результатах должно быть написано, как конкретно мы понимаем, что (например) поле изменило свое значение - Все тесты проверяют, «успешно» ли (в соответствии с ожиданиями) работает наше ПО. Это подразумевается и так, даже если мы нигде никогда не напишем в тестах слово «успешно»
Немного о личном опыте: иногда у меня получается сократить чужой тест в 2 раза просто за счет упрощения формулировок. Моя команда давно так не пишет, но порой из тьмы веков всплывают древние ископаемые и с ними приходится что-то делать.
Пишу про тесты не в первый раз, не в последний и даже не в предпоследний. Слишком большая тема:)
Сегодня я хочу поговорить про слова, которыми мы записываем тест. Какие тут могут быть проблемы: лишние слова, длинные слова, сложные слова.
Казалось бы - ерунда. Какая разница, напишем мы где-то одно слово вместо двух.
Не побоюсь прослыть занудой, которая экономит буковки. Слова, которые присутствуют в тесте и при этом не привносят ценность - это лишнее время на чтение и осознание прочитанного. Они создают визуальный шум и сбивают с фокуса.
В каком-то смысле слова - это наш код) Это скрипт, который объясняет человеку, что нужно делать, чтобы что-то проверить.
На нашем проекте примерно 20 000 тестов. Допустим, в каждом тесте всего одно лишнее слово. 20 000 строк кода, которые приносят ноль пользы!
Иногда лишние или более длинные слова используются, потому что это выглядит более наукообразно и солидно. У меня не какие-то там Steps, у меня Input specification. Иногда просто берется шаблон (например, из стандарта) и применяется как есть, без адаптации. Думаю, есть и другие причины (в том числе «не подумали, что так можно»). Но если у вас не супержесткие требования к документации (например, нужно по закону соответствовать определенным стандартам), то, скорее всего, можно договориться с командой и писать тесты в другом стиле. Скорее всего, вы-из-будущего скажете себе-из-настоящего большое спасибо.
Сложные предложения: тут все аналогично.
Когда текст теста состоит из сложносочиненных/сложноподчиненных предложений, наукообразных слов, витиватых формулировок и прочих велеречивых словоречений (с) - мы стреляем себе в ногу. При таких условиях даже чтение простых тестов требует больших усилий, что уж говорить про сложные.
Поэтому я за то, чтобы упрощать все, что можно упростить, и экономить силы для другого. Например, на критическое осмысление теста и само тестирование.
Successful
Вынесу это слово в отдельный пункт, потому что причиняет мне отдельную сильную боль (наряду с табличным форматом тестов, но о нем я напишу когда-нибудь потом).
Не знаю, как это слово просачивается в документацию. Возможно, вайбы Линкедина, рекомендаций по написанию резюме и прочего успешного успеха так сильны, что людям сложно написать «значение поля в базе изменилось» и вместо этого они автоматически пишут «значение поля в базе успешно изменилось». Возможно, люди думают, что без «успешно» формулировки выглядят недостаточно весомыми. В чем разница между «значение изменилось» и «значение успешно изменилось», мне пока никто не смог объяснить (я спрашивала).
Что могу тут сказать:
- «Успешно» в результатах теста это очень неконкретное понятие и не может быть критерием того, пройден тест или нет. В результатах должно быть написано, как конкретно мы понимаем, что (например) поле изменило свое значение - Все тесты проверяют, «успешно» ли (в соответствии с ожиданиями) работает наше ПО. Это подразумевается и так, даже если мы нигде никогда не напишем в тестах слово «успешно»
Немного о личном опыте: иногда у меня получается сократить чужой тест в 2 раза просто за счет упрощения формулировок. Моя команда давно так не пишет, но порой из тьмы веков всплывают древние ископаемые и с ними приходится что-то делать.
BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260
For tech stocks, “the main thing is yields,” Essaye said. The regulator took order for the search and seizure operation from Judge Purushottam B Jadhav, Sebi Special Judge / Additional Sessions Judge. However, the perpetrators of such frauds are now adopting new methods and technologies to defraud the investors. Soloviev also promoted the channel in a post he shared on his own Telegram, which has 580,000 followers. The post recommended his viewers subscribe to "War on Fakes" in a time of fake news. The last couple days have exemplified that uncertainty. On Thursday, news emerged that talks in Turkey between the Russia and Ukraine yielded no positive result. But on Friday, Reuters reported that Russian President Vladimir Putin said there had been some “positive shifts” in talks between the two sides.
from us
