К сожалению, большинство програмеров не понимает, что юнит-тесты не тестирование как таковое, а прежде всего инструмент для дизайна какой-то отдельной фичи или функционала приложения. Да, можно писать и дизайнить без тестов, то при таком "быстром подходе" велика вероятность ошибок из-за плохой продуманности задачи и ее решения. С тестами, особенно если используется TDD, задачу оценить, обдумать удается гораздо лучше, а значит и конечный результат в коде будет лучше.
Проблема в том, что в мобильной разработке бизнес логики не так много. А обвешивать тестами методы, которые там в разных потоках что-то делают или анимации какие-то просчитывают- ну такое себе.
@@dmitriyobidin6049 Ну, хорошо, вы написали без тестов, оно скомпилировалось. Далее как вы проверяете, что оно работает так как вы ожидаете? Запускаете на выполнение, прокликиваете кнопочки, вводите данные в поля и все это ручками проделываете, неужели не заебывает? Или забиваете болт, раз оно скомпилировалось, значит работает! Как делаете вы? Как вы доказываете своему руководителю, что фичу вы реализовали? Мне просто интересно.
Подача шикарная, подбор информации великолепен! Но есть увтерждения, с которыми я не могу согласиться. Если компания всё же беспокоится о качестве продукта, либо он имеет критичное влияние на что-то (не обязательно такое, как в примере с Боингами, хватит и банковских счетов клиентов), отсутствие юнит-тестов, других автотестов (интеграционных, например) приведёт к необходимости постоянного, долгого и очень муторного регрессного тестирования. Лично был свидетелем ситуации, когда набор фичей для продукта пилился месяц, а регрессное тестирование перед выводом новой весии в прод занимало два месяца. Собственно, к чему я - в этом случае написание автотестов в процессе разработки скорее всего поможет ОЧЕНЬ ЗДОРОВО сократить TTM (time-to-market). То есть, автотесты вообще и юнит-тесты в частности вполне могут быть и прямым драйвером получения прибыли (выкатили быстрее, быстрее начали на этом зарабатывать).
Разработчикам порекомендовали то, что они никогда не будут делать. Всем плевать, что такое тестирование, как там все утроено, разбираться будут единицы. А вот заставить написать один инструментальный тест на свой код, может даст понимание, как писать ТЕСТИРУЕМЫЙ код, а не петушню в одну калитку. Большая часть даже не задумывается о тестируемости кода, когда пишут в продукт.
Нормально делай - нормально будет(короткий ответ на вопрос про правильное написание тестов)! Столько сложностей и убытков, что любой манагер решит ну нахер - проще за чашку риса нанять толпу которая руками все протыкает
