Надежное программное обеспечение может быть быстрым в реализации.
Тестирование программного обеспечения зачастую воспринимается клиентами как нечто усложняющее общий процесс, и как то, что имеет мало общего с настоящими потребностями обычных людей и удлиняет процесс разработки.
Программисты же обычно не пишут тесты, потому что нужно постоянно реализовывать новые функциональные возможности программы, а написание тестов требует дополнительного времени.
Из-за таких точек зрения возникает довольно типичная ситуация. Разработчики под давлением менеджмента, ругая управленцев, пишут код по 12 часов в сутки, и все же не успевают реализовать все потребности клиента, поскольку слишком часто все ломается. А заказчик давит на менеджмент со сроками конечного продукта и хочет, чтобы уже хоть что-нибудь было в нормальном работающем состоянии.
Конечно данная картина может быть представлена в различных оттенках негатива, но общая суть остается одинаковой - в любом подобном проекте накапливается отрицательные эмоции, у обеих сторон процесса неизбежно возникает конфликт. Некоторые опытные люди даже рассматривают это как нормальное течение проекта, - его жизненный цикл.
Однако для этой ситуации давно придумано решение. Это решение — написание тестов.
Давайте посмотрим на то, как тесты влияют на течение проектов и их успешность:
- Изменяемость кода в целом выше у кода покрытого тестами. Программисты не боятся его оптимизировать под актуальное состояние системы, а это приводит к тому, что со временем разработчикам проще дорабатывать функциональность системы. Они просто это делают быстрее, потому что не боятся обрушить какую-то из частей. Для клиента это означает более быстрый темп развития программного продукта.
- Написать тест крайне редко занимает более пары часов. Однако код, непокрытый тестами, даже при условии отсутствии текучки кадров, в течение полугода будет требовать больших временных затрат на исправление багов и тестирование этого участка в ручном режиме.
- Также при написании тестов у разработчиков возникает более подробное понимание того, как нужно, чтобы работала система в этом участке. Тесты служат источником знаний о том, как функционирует программное обеспечение для тех, кто пишет код, и еще не знаком с определенным модулем в системе, даже при отсутствии документации в целом.
- Снижается отрицательное влияние человеческого фактора в рамках проекта. Для уставших разработчиков меньше шансов сломать код системы.
Однако, у этой идеи есть и свои потенциальные подводные камни.
- Если тесты написаны архитектурно неправильно, то любое изменение кода без изменения функциональности потребует переписать тесты, связанные с этим участком. Возникает, так называемый, ад тестирования, когда любое изменение системы затягивается как минимум в два раза.
- Также написанные тесты не гарантируют того, что система будет работать корректно на 100%, потому что разработчики могут пропустить и забыть протестировать важные граничные условия функций системы или попросту написать чересчур общий тест, который будет успешно проходиться, даже если реализация кода будет некорректной.
- Если тесты пишутся после написания функционального кода, то велик риск того, что будет написано много лишних строк, которые не несут дополнительных возможностей для системы, или какие-то возможности останутся непротестированными.
Конечно для уменьшения влияния всех этих подводных камней на процесс разработки есть отдельный набор различных техник. Но в этой статье мы на нем останавливаться не будем (разберем это в других статьях).
