Comments 23
Я встречал в своей практике ассерт на true, который разумеется всегда срабатывал. Ревью коллег, которые пишут такие же ассерты, может не помочь.
Для таких тестов можно использовать мутационное тестирование, которое поможет выявить accert на true.
Я с гордостью могу сказать, что у нас время от создания pull request до попадания кода в репозиторий сейчас составляет около 30 минут.
Привет! Не очень понятно, если у вас 30 минут — это время сборки, то как за 30 минут вы успеваете всё это вмёрджить? Я имею ввиду, чтобы 2 разрабочтика провели ревью кода, нужно довольно много часов, наверное (пока программисты найдут у себя время, пока скажут своим замечания, пока код будет поправлен). Или я что-то упускаю?
Главное — не фиксить старые баги, а следить за тем, чтобы не было новых
Вот поэтому сейчас весь софт и глючит, обидные баги, которые можно за пять минут пофиксить — годами висят. Главное что тесты проходит все приложение. А эти минорные баги — подождут, довольно часто до смерти продукта.
Вы вырываете фразу из контекста. Речь шла про баги в старом коде, найденные статическими анализаторами. Обычный пользователь такие "баги" не увидит никогда. При этом чинить их просто вредно, т.к. можно сделать настоящие баги вместо мнимых.
Попробуйте прогнать статический анализ кода на своем проекте. Если раньше не гоняли и не исправлял, вам найдут 100500 проблем, большая часть которых будет False Positive по разным причинам. Их чинить не надо. True Positive же разделятся по важности, от неизбежно приводящих к ошибкам и крешам (blocker) до предложений по улучшению кодстайла. Блокеры мы обязательно все исследуем и чиним. Не блокеры почти всегда чинить нецелесообразно, это будут изменения ради изменений. Люди не любят таким заниматься
Кейс такой — Едете вы на работу в метро, открываете яндекс.браузер и тут бац, параллельно запускаются карты, навигатор, парковки и такси.
В результате 50% CPU телефона занято непонятно чем, все начинает тормозить, музыка в наушниках подвисать, а Вы тут хвастаетесь успехом в разработке?)))
Мы на проекте тоже решили покрывать тестами и пока еще стонем от этой боли, но вера в то что все будет хорошо пока живет)
Как вы имплиментируете новый функционал? Вы используете TDD, или разрабатываете функционал, а потом покрываете его тестами, или тесты пишутся строго в отведенные 30% каждого месяца?
У нас есть test smells, отдельная страничка, где фиксируются типичные проблемы, которые возникают при написании тестов в режиме «так плохо, а так было бы хорошо»
А насколько специфична данная страничка? Есть там общие моменты в области написания текстов? Ее можно причесать и выложить на Хабр? Было бы очень любопытно взглянуть.
Во имя связности интернета, оставлю ссылки. Выложил на гитхаб и рассказал голосом
https://m.habr.com/ru/company/yandex/blog/436850/
https://github.com/kzaikin/test-smells
Как мы контролируем качество кода в Браузере для Android. Лекция Яндекса