shishmakov 12 ноя 2020 в 11:00

Тесты, деньги и техдолг (сказ из жизни одного Java-проекта)

19 мин

Блог компании ДомкликJava*Тестирование веб-сервисов*

Дорогой друг, эта статья отчасти о тестировании, а отчасти о деньгах и жизни. Я написал её после того, как в очередной раз пришлось рассказывать новому сотруднику команды о том, как мы пишем тесты, когда и почему мы это делаем. Теперь я просто буду давать на эту статью ссылку, чтобы не повторяться. Я выражаю свой личный взгляд и мнение, надеясь, что и тебе он тоже будет полезен.

Сказ мой о разработке на Java, при этом всё нижеизложенное справедливо и для других языков программирования. От смены языков люди и проблемы в тестировании не меняются.

Отказ от ответственности (aka disclaimer): все персонажи являются вымышленными, и любое совпадение с реально живущими или когда-либо жившими людьми случайно.

Что вы узнаете из этой статьи:

зачем программисты пишут тесты;
почему программисты НЕ пишут тесты;
как быстрее «вводить» новых людей в проект;
кто такие нигилисты и причём здесь деньги.

Кому может быть интересна эта статья:

программистам-одиночкам, не привыкшим работать в команде;
студентам, только начинающим работать в коллективе.
всем у кого тесты в проекте как дитя-сирота: не накормлена и не обута.

Прежде чем начать, придётся дать немного теории. Знаю, это занудно, но что поделать...

Очень важно, чтобы в вашей команде разработка ПО велась с использованием Continuous Integration, она же CI, она же «Непрерывная Интеграция».

Continuous integration — это практика разработки, которая требует работать с единым репозиторием кода, часто его актуализировать, объединять с основной веткой кода, автоматически тестировать для проверки работоспособности.

Это позволяет командам находить ошибки на ранней стадии, решать интеграционные проблемы.

Конечная цель — получить работоспособный артефакт проекта.

CI Pipeline

Процесс выглядит так:

Есть репозиторий, в котором мы храним текстовые файлы с исходным кодом программы.
Необходимо их достать, скомпилировать и прогнать тесты.
Получившуюся программу записать в бинарный файл, например, в Docker-образ, с помощью команды docker build.
Конечный артефакт сохранить в репозиторий бинарных файлов.

В ходе сборки крайне желательно протестировать программу:

выполнить заранее написанные модульные (unit) тесты;
выполнить заранее написанные функциональные (functional) тесты;
провести дымовое тестирование (smoke testing);
выполнить интеграционные тесты если они являются частью вашего проекта.

Дорогой друг, ты получаешь артефакт, чтобы позднее развернуть программу в каком-то окружении. Чтобы не было двойного толкования по разным видам тестов, я объясню своими словами, что это такое.

Модульное тестирование (unit testing)

Применяется для проверки малого независимого блока кода: утилитных методов, методов с бизнес-логикой.

Пример: конвертирование входных данных из объекта A в результирующий объект Б.

@Test
void defineBirthdayShouldReturnDateSuccessfully() {
   LocalDate expectedDate = LocalDate.of(1991, 5, 29);
   String sourceData = "1991 05 29";

   LocalDate resultDate = projectService.defineBirthday(sourceData);
   assertEquals(expectedDate, resultDate);
}

Функциональное тестирование (functional testing)

C его помощью проверяется функциональная связность нескольких блоков для решения одной общей задачи. Пример: создание пользователя:

проверить входящие данные;
создать записи в основной таблице;
создать записи в таблице аудита;
проверить исполнение.

@Test
void nextUserShouldPersistUserObjectSuccessfully() {
   User user = buildTestUser();
   UserAudit userAudit = buildTestUserAudit(user);   
   doReturn(user).when(userDAO).saveUser(eq(user));
   doReturn(userAudit).when(userAuditDAO).saveUserAudit(eq(userAudit));

   projectService.nextUser(user);

   verify(userDAO).saveUser(eq(user));
   verify(userAuditDAO).saveUserAudit(eq(userAudit));
}

Дымовое тестирование (smoke testing)

В названии есть игра слов, которая пришла из электротехники: после сборки схемы цепи её включали в сеть и смотрели, не пошёл ли где дым. По сути, это простой интеграционный тест, с помощью которого проверяются основные функции продукта, без работы которых взаимодействовать дальше нет смысла. Такие тесты легче писать, чем интеграционные, а ведь наша главная задача — быстрее узнать о проблеме.

Пример: backend-слой не женится c web-слоем, о чём может сообщить ошибка, к примеру, с Dependency injection.

@Test
public void getPingShouldReturnSuccessResponse() {
   ServerResponse response = executeGet("/ping");
   StatusDTO responseDTO = MAPPER.readValue(response.body, StatusDTO.class);

   assertEquals(OK_200, response.code);
   assertEquals(new StatusDTO("up"), responseDTO);

   verify(rabbitService).hasRabbitConnection();
}

Интеграционное тестирование (integration testing)

Главный вид тестов. Мы проверяем не какие-то маленькие элементы программы, а задачи, функционально затрагивающие несколько служб, поэтому кода может быть на порядок больше. Интеграционные тесты могут быть или частью вашего проекта, или вынесены в отдельный проект, или оба варианта вместе. В первом варианте вы работаете с локально поднятыми службами (message queue, database) + используете HTTP Mocks, эмитируя ответы сторонних сервисов. Во втором варианте вы проверяете работу вашего сервиса и его взаимодействие с другими сервисами в окружениях QA/Stage.

Пример (2ой вариант): этапы смены пароля пользователя:

проверка пароля и пароля для будущей замены;
создание нового тестового пользователя;
проверка аутентификации нового пользователя;
отправка запроса для службы SMS-уведомлений о смене пароля;
смена пароля с кодом из SMS;
проверка аутентификации пользователя с новым паролем;
удаление тестового пользователя.

Код

@Test
public void stage001_validateUserPasswords() {
   String password = genPassword();
   String nextPassword = genPassword();
   setPassword(password);
   setNextPassword(nextPassword);

   List.of(password, nextPassword).forEach(pwd -> {
       var dto = PasswordValidateRequest.builder().password(pwd).build();
       ResponseEntity<Void> response = restTemplate
               .postForEntity(baseUrl + API_USERS_URI + "/PasswordValidateRequests", dto, Void.class);
       assertEquals(HttpStatus.OK, response.getStatusCode());
   });
}

@Test
public void stage002_createNewUser() {
   String login = buildPhoneNumber();
   String password = getPassword();
   setLogin(login);

   UserDTO dto = buildUser(login, password, INTERNET);

   HttpHeaders headers = new HttpHeaders();
   headers.add(ACCESS_HEADER, ACCESS_TOKEN);
   HttpEntity<UserDTO> httpEntity = new HttpEntity<>(dto, headers);
   ResponseEntity<UserDTO> response = restTemplate
           .exchange(baseUrl + SRV_USERS_URI, HttpMethod.POST, httpEntity, UserDTO.class);

   UserDTO data = response.getBody();
   assertEquals(HttpStatus.CREATED, response.getStatusCode());   
   assertNotNull("response data is null", data);
   setUserId(data.getId());

   assertNotNull("user id undefined", data.getId());
   assertEquals("user login undefine", login, data.getUserName());
   assertTrue("user is not active", data.getActive());
}

@Test
public void stage003_readUserByAuthSuccessfully() {
   readUserByAuth();
}

@Test
public void stage010_sendSmsNotificationToRestorePassword() {
   String phone = getLogin();
   UserPhone dto = new UserPhone(phone);

   ResponseEntity<Void> response = restTemplate
           .postForEntity(baseUrl + API_USERS_URI + "/restore_password", dto, Void.class);
   assertEquals("SMS hasn't sent", OK, response.getStatusCode());

   var notification = notificationRepository.findLastByPhone(phone);
   assertEquals("SMS_RESTORE_PASSWORD_CODE", notification.getSmsTemplate());
   assertNotNull("no confirm SMS data", notification.getContentData());

   var smsData = smsDataReader.readValue(notification.getContentData());
   assertNotNull("no sms code", smsData.getCode());

   setSmsConfirmCode(smsData.getCode());
}

@Test
public void stage011_patchShouldChangeUserPasswordBySmsCode() {
   String smsCode = getSmsConfirmCode();
   String login = getLogin();
   String nextPassword = getNextPassword();
   setPassword(nextPassword);

UserPhonePassword dto = UserPhonePassword.builder()
       .password(nextPassword).phone(login).code(smsCode)
       .build();
   HttpEntity<UserPhonePassword> httpEntity = new HttpEntity<>(dto, new HttpHeaders());
   ResponseEntity<Void> response = restTemplate.exchange(baseUrl + API_USERS_URI + "/password", PATCH, httpEntity, Void.class);
   assertEquals(HttpStatus.OK, response.getStatusCode());
}

@Test
public void stage012_readUserByAuthSuccessfully() throws IOException {
   readUserByAuth();
}

@Test
public void stage099_deleteUser() {
   Object userId = getUserId();
   HttpHeaders headers = new HttpHeaders();
   headers.add(ACCESS_HEADER, ACCESS_TOKEN);
   HttpEntity<?> httpEntity = new HttpEntity<>(HttpEntity.EMPTY, headers);

   ResponseEntity<String> before = restTemplate.exchange(baseUrl + SRV_USERS_URI + "/{id}", HttpMethod.GET, httpEntity, String.class, userId);
   assertEquals(HttpStatus.OK, before.getStatusCode());

   ResponseEntity<Void> response = restTemplate.exchange(baseUrl + SRV_USERS_URI + "/{id}", DELETE, httpEntity, Void.class, userId);
   assertEquals(HttpStatus.NO_CONTENT, response.getStatusCode());

   ResponseEntity<Void> after = restTemplate.exchange(baseUrl + SRV_USERS_URI + "/{id}", HttpMethod.GET, httpEntity, Void.class, userId);
   assertEquals(HttpStatus.NOT_FOUND, after.getStatusCode());
}

private void readUserByAuth() throws IOException {
   String login = getLogin();
   String password = getPassword();
   HttpHeaders headers = authHeaders(login, password);
   headers.add(ACCESS_HEADER, ACCESS_TOKEN);
   HttpEntity<?> httpEntity = new HttpEntity<>(HttpEntity.EMPTY, headers);

   ResponseEntity<String> response = restTemplate.exchange(baseUrl + SRV_USERS_URI + "/me",GET, httpEntity, String.class);
   assertEquals(OK, response.getStatusCode());

   UserDTO data = userReader.readValue(response.getBody());
   assertNotNull("user id undefined", data.getId());
   assertTrue("user is not active", data.getActive());
}

Дорогой друг, последовательность вызова методов в интеграционном тесте проверяет тот же сценарий, которым будет пользоваться клиент на боевом сервере. Наша задача — точно узнать, что ни на одном из этапов мы не зафакапили, и на выходных можем нормально почилить, а не сидеть за компутером вместо тусовочки с бестфрендами.

Проблемы на практике

В теории всё гладко: тесты пишутся, сервисы деплоятся, ~~лавэха му~~ довольные клиенты платят деньги = профит. На практике возникают проблемы… проблемы в применении того, что было озвучено выше.

Здесь-то, мой дорогой друг, и начинается история нашего героя. Позволь представить тебе молодого программиста… Большой Крис.

Фото старое, из прошлой жизни Криса. Не переживай, Большой Крис нормальный спокойный парень, недавно отсидевший за угон автомобиля с отягчающими обстоятельствами. Крис решил, что стоит изменить свою жизнь и вступить на путь истинный, став программистом. Ну, не таксовать же всю жизнь, в самом деле? Реклама в Ютубчике так и трубит, что программисты очень нужны, и деньжата у них, вроде бы, водятся. Вот и решил Крис, что лучше делать хорошие правильные вещи, работать с умными людьми и зарабатывать деньги. Иначе зачем ты вообще читаешь эту статью?

Изучил он парочку онлайн-курсов, прочитал «Чистый код» Роберта Мартина, прошёл несколько собеседований на позицию Java Junior Developer, и был принят на работу. В назначенный день Крис приходит в команду молодым разработчиком. Ему говорят: «Вот тебе наш проект. Можешь с ним ознакомиться».

Крис видит, что проект хранится в репозитории Git, поэтому первым делом скачивает его на рабочий компьютер командой:

git clone https://internet.com/any-repo/money-transfer.git

Затем запускает команду сборщика проекта. Обычно это либо Gradle, либо Maven:

$ ./gradlew clean build
$ ./mvnw clean package

Но ничего не получается, во время прохождения тестов возникают какие-то ошибки:

Tests in error:
 restorePasswordByCall_Phone(uk.bank.services.UserServiceTest): PreparedStatementCallback; SQL [INSERT INTO authorities(user_id, authority) VALUES (?, ?)]; ERROR: deadlock detected(..)
 restorePasswordByCall_Phone(uk.bank.services.UserServiceTest): StatementCallback; uncategorized SQLException for SQL [truncate users cascade]; SQL state [25P02]; error code [0]; ERROR: current transaction is aborted, commands ignored until end of transaction block; nested exception is org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block
 getUsersAuthoritiesShouldGetMapRoles(uk.bank.services.UserRoleServiceTest): StatementCallback; SQL [truncate users cascade]; ERROR: deadlock detected(..)
 getUsersAuthoritiesShouldGetMapRoles(uk.bank.services.UserRoleServiceTest): StatementCallback; uncategorized SQLException for SQL [truncate authorities cascade]; SQL state [25P02]; error code [0]; ERROR: current transaction is aborted, commands ignored until end of transaction block; nested exception is org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block

Если присмотреться, то можно заметить:

ERROR: current transaction is aborted, commands ignored until end of transaction block

Поясню: приложение проигнорировало ошибку в транзакции и продолжило формировать запросы дальше.

Крис хмурит брови, подходит к кому-то из команды и спрашивает: «Что это такое?». Ему отвечают: «Какая-то странная ошибка. Попробуй ещё раз».

Попытка №2. Возникает другая ошибка:

Caused by: org.postgresql.util.PSQLException: Connection to 172.18.18.18:5463 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
  at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:247)

Ключевое здесь:

PSQLException: Connection to 172.18.18.18:5463

Поясню: на этот раз пропало соединение с VPN. Как правило, в компаниях есть своя собственная внутренняя сеть, и мы видим, что к ней идёт подключение. Так бывает, что внутренние сервисы могут быть доступны только внутри локальной сети компании. И оказывается, что для простой сборки проекта и прохождения тестов необходимо быть подключенным к VPN. Крис с прежним вопросом обращается к команде. Ему предлагают попробовать в третий раз.

Попытка №3. Проект собрался, даже подключился через VPN к какому-то сервису. И тут вылетает новая ошибка:

14:34:51.127 [XNIO-2 task-4] ERROR uk.bank.controllers.ControllerV1Test name=createUser - exception, /v1/users
java.lang.IllegalStateException: error parse person for user: 32000140
  at uk.bank.services.PersonClient.parsePersonData(PersonClient.java:173)

Обращаем внимание:

java.lang.IllegalStateException: error parse person for user

Поясню: на этот раз тесты обращаются к некоторому внешнему сервису Person, а тот, скорее всего, был недоступен, и поэтому вернулась ошибка 500 Internal Server Error.

В голове Криса стал крутиться один и тот же вопрос: «Какого х@#?!». Хоть и немного раздражённый, он не стал озвучивать его, и по привычке просто перезапустил сборку проекта заново. Аллилуйя, на этот раз всё получилось!

Results :

Tests run: 278, Failures: 0, Errors: 0, Skipped: 5

... 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:12 min
[INFO] Finished at: 2020-10-18T14:10:03+03:00
[INFO] ------------------------------------------------------------------------

Итог: рабочий день только начался, а новый программист в команде уже столкнулся с большим количеством проблем на ровном месте. «Старички» никак не объясняли происходящее, а просто заставляли перезапускать сборку проекта до тех пор, пока она не пройдёт успешно. «У меня всё работает, ты что-то делаешь не так», — было их обычным ответом. Вы думаете, это какой-то прикол и такого не бывает в реальной жизни?

Вот и Большой Крис подумал, что стал участником какой-то шутки, забавы или «посвящения», как когда-то в армии бывало. Это было первой ошибкой команды.

Дорогой друг, а что бы ты сделал на месте Большого Криса? Правильный ответ: стоит посмотреть на тесты в проекте. Это первое, с чем должен ознакомиться любой программист, начиная работу над новым проектом. Так как именно с ними у Криса возникли первые проблемы, то это вполне логичное решение. Итак, взглянем…

@Test
public void find_user_by_phone_error() {
   when(userServiceV2.findUserByPhoneAndMail(PHONE, EMAIL))
           .thenReturn(null);
   when(userServiceV2.findUserByPhoneAndMailIsNull(PHONE))
           .thenReturn(null);

   mockMvc.perform(get(END_POINT)
           .param("phone", PHONE)
           .param("email", EMAIL)
           .accept(APPLICATION_JSON)
           .contentType(APPLICATION_JSON))
           .andDo(print())
           .andExpect(status().isBadRequest())
           .andExpect(content().contentType("application/json;charset=UTF-8"))
           .andExpect(jsonPath("$.success", is(false)))
           .andExpect(jsonPath("$.errors[0].code", is(ErrorDTO.PHONE_ALREADY_IN_USE.getCode())))
           .andExpect(jsonPath("$.errors[0].userMessage", containsString("Восстановите пароль")));
}

@Test
public void testCarlineService() {
   RestTemplate restTemplate = new RestTemplate();
   UserWrap userWrap = new UserWrap();
   userWrap.setTransactId("tran123");
   userWrap.setId(123L);
   HttpEntity<UserWrap> entity = new HttpEntity<>(userWrap);
   ResponseEntity<UserWrap> response = restTemplate.exchange(portalSbernedHost + unitUrl, HttpMethod.POST, entity, UserWrap.class);
   System.out.println("response: " + response.getStatusCode());
}

Двух первых тестов достаточно, чтобы возникли вопросы к проекту:

Какие правила именования тестовых методов используются в проекте?
В названии первого теста слова разделяются подчёркиванием, в названии второго теста каждое новое слово начинается с прописной буквы. И похоже (по другим тестам), что всех всё устраивает.
Что необходимо использовать в тестах: MockMvc, или RestTemplate, или TestRestTemplate?
Конкретный проект написан на Java с использованием Spring Framework.
Есть RestTemplate, используемый в боевом коде для взаимодействия по HTTP. TestRestTemplate — это обёртка над RestTemplate для работы в тестах, не бросающая исключения при получении кода ошибки 5xx.
MockMVC создан для тестирования только web-слоя сервиса. Оба теста были в одном тестовом классе. Нехорошо как-то.
Почему в тестах мы видим разные способы тестирования?
Всё выглядит так, словно каждый программист пишет тесты как ему нравится, или как у него получается их написать, без выделения общих подходов и code review.
Есть ли правила работы с mock/spy-объектами?
В первом методе есть ключевые слова when и thenReturn. То есть имеется объект, у которого вызывается некий метод. Мы подставляем обманку, говоря, что если вызывается метод M, то нужно вернуть значение N. Однако в конце теста не проверяется выполнение этих методов, действительно ли они вызывались, действительно ли мы вернули то, что ожидали.
В возвращаемых значениях используется null
В этом нет ничего хорошего. При работе с ним возможны многие проблемы, и если можно, то лучше уйти от такого применения, используя правильные возвращаемые объекты. Наличие null — явный признак того, что и в бизнес-логике проекта он часто используется. Пахнет плохим кодом.
Есть ли правила вывода информации на печать?
В тексте второго теста с помощью System.out.println выводится информация о возвращаемом HTTP-коде. Это не слишком хорошее решение, лучше использовать библиотеку для работы с логами. Тогда можно переключать и сегментировать информацию: выводить лишь предупреждения и ошибки (warn), что-то в режиме отладки (debug). Здесь же ничего подобного нет, просто текст в консоли.
Вы понимаете, что посмотреть глазами вывод на печать — это единственная проверка в данном тесте? Нет ни assertEquals, ни assertTrue. Очень странный тестовый метод, зачем вообще он нужен, если ничего не проверяет и не даёт автоматизированной обратной связи?

Выводы

Каждый новый сотрудник компании может:

увидеть плохой код в тестовых методах;
увидеть тесты, которые ничего не проверяют;
понять, что если тесты написаны плохо — значит, то же самое будет и в бизнес-логике проекта.

Вопросы

Кто всё это писал?
Кто позволил всё это написать?

Дорогой друг, это именно те вопросы ради которых я начал писать эту статью. Дело в том, что Большой Крис пришёл в команду профессионалов, на проект, которым пользуются клиенты компании. Он мотивирован начать новую жизнь, обрести новые знакомства, перенять опыт умных людей. Что Крис встретил в итоге?

Проблема №1

Проект «ИКС» компании «Рога и Копыта» очень важен. Он приносит деньги основателям бизнеса, кормит саму команду разработки и позволяет внедрять новые проекты, ещё не достигшие безубыточности. Как я упомянул ранее, в коллективе уже работают профессионалы, каждый из них эффективно справляется со своей работой и за короткие сроки внедряет новые фичи, исправляет возникшие баги. Такой режим работы не позволяет не только тесты написать, а даже проект изучить. Как итог, общее дело превращается в лоскутное одеяло.

Проблема №2

У Большого Криса ещё мало опыта, и он не знает, что культура в команде не сформирована, а отношения извращены: его мнение, как молодого программиста, никому не интересно.

— Я вижу, что тесты не помогут мне понять, как работает проект, они сами периодически не работают, а некоторые просто ничего не делают. Может, проведём общую встречу для всей команды? Я читал в одной книге… — начал говорить Большой Крис

— Слушай, я сейчас занят. Давай позже, или обратись к тимлиду, — ответил product owner проекта.

— Не думаю, что у нас есть какие-то проблемы, — ответил тимлид.

— Но тесты не работают и написаны очень странно. Может мне кто-нибудь помочь? — выпалил Крис, не сдержавшись.

— Ты здесь первый день и уже всем мешаешь. Можешь не отвлекать от работы? — ответил ему Senior Certified Java Programmer.

Краткий и ёмкий диалог. Большой Крис всё запомнил. Это стало второй ошибкой команды.

Желания сделать лучше, упорядочить архитектуру и написать хорошие тесты, как правило, разбиваются:

о монолитность кода;
о большое количество изменений, которые придётся сделать;
о невозможность быть уверенным в сохранении работоспособности и правильного взаимодействия с другими сервисами, потому что нет тестов.

Дорогой читатель может возразить, что отсутствие тестов может быть оправдано:

Ведь программистам не за тесты платят деньги, а за фичи…
На тесты необходимо дополнительное время, а его нет и нужно фичи пилить…

Выводы

в команде нет культуры, а значит нет и правил;
если в команде нет правил, то никто не подконтролен;
если в команде никто не подконтролен, то образуется технический долг.

Если программистам платят деньги за фичи, и в проекте нет тестов, то возрастает время на реализацию новой функциональности и, как следствие, на исправление возникающих ошибок. В результате фичи превращаются в постоянный рефакторинг кода. Как итог, программисты тратят всё больше времени… на рефакторинг, который не улучшит ситуацию, потому что… в команде нет культуры написания кода. Образуется новый техдолг. Цикл замкнут.

Технический долг — это проблема, которую не решили вовремя и отложили на будущее. Сейчас он не может препятствовать введению новой функциональности, но в будущем может проявиться в какой-то задержке, в проблеме, которую нельзя решить вовремя и быстро. Придётся потратить время на решение (исправление) этого долга.

Дорогой читатель, если ты ещё не понял, объясню: в проекте не может быть второстепенных частей. Команде, занимающейся разработкой проекта, важно:

и писать новую функциональность;
и покрывать свой код тестами;
и повышать культуру разработки и общения внутри коллектива.

Получается, компания тратит деньги не на фичи, а на нигилистов, которые не желают быть командными игроками. Всё, что их окружает, это технический долг, который позволяет им оставаться незаменимыми. Они могут быстро править баги, потому что сами их и создали.

Нигилизм (от лат. nihil — ничто) — философия, ставящая под сомнение общепринятые ценности, идеалы, нормы нравственности, культуру. Нигилизм подразумевает отрицание, негативное отношение к определённым, или даже ко всем сторонам общественной жизни.

«Не будь нигилистом Senior Certified Java-программистом», — сказал бы И. В. Тургенев сейчас. Чтобы не спойлерить сюжет, читайте его книгу «Отцы и дети» о Евгении Базарове.

Задайтесь вопросом: «Если всё получается сейчас, будет ли так и дальше, когда из команды уйдут те самые Senior Certified Java-программисты?». Увы, если знания не формализованы в коде через тесты и не создан самоподдерживающийся каркас проекта из тестов, то вас ждут проблемы с введением в проект новых людей.

Дорогой друг, позволь свои слова подкрепить цитатой из ещё одной книги, «Шаблоны реализации корпоративных приложений» за авторством Кент Бека:

ПО должно быть спроектировано так, чтобы уменьшалась его общая стоимость. Она делится на начальную стоимость разработки и стоимость сопровождения:

Когда в индустрии был накоплен достаточный опыт разработки ПО, для многих стал сюрпризом тот факт, что начальная стоимость гораздо ниже стоимости сопровождения.

Сопровождение обходится дорого, поскольку понимание кода — это процесс, занимающий много времени и подверженный ошибкам. Внесение изменений существенно облегчается, если известно, что именно требуется изменить. Изучение существующего кода является самой трудоёмкой частью. Все вносимые изменения должны быть протестированы и внедрены.

… Сегодняшний доллар не должен стоить дороже завтрашнего.

Давайте закругляться, а то я что-то много уже написал. Перейдём сразу к рекомендациям, которые позволят уменьшить технический долг проекта. Сразу оговорюсь, что нам не нужен идеальный код в тестах, здесь не будет стратегии TDD, BDD и деклараций Given-When-Then. Нам нужен код, который можно быстро читать, быстро править и дополнять. Всё это моё ИМХО из работы над проектами и общения с живыми людьми.

Итого

Время — это ваш актив. Техдолг — это ваш пассив.
Актив — это то, что приносит доходы. Пассив — это то, что приносит расходы.
Тесты — это материальная форма выражения актива, а отсутствие тестов — чёрная дыра пассива.

Тесты будут возвращать дивиденды, экономя ваше время на всём протяжении жизни проекта. От техдолга не уйти, он всегда будет, пока жив проект и ведётся работа. Ваша задача — стараться держать техдолг в рамках разумного.

Постскриптум (aka P.S.)

Дорогой читатель, у Большого Криса всё хорошо. После неудачного первого рабочего дня он решил познакомиться со своими коллегами чуть поближе и пригласил их на пикник, любезно согласившись подвезти на своём автомобиле. Это была первая встреча Архитектурного Комитета, после которой никаких проблем в общении больше не было, но это уже совсем другая история.

Теги:

Хабы:

Тесты, деньги и техдолг (сказ из жизни одного Java-проекта)

Прежде чем начать, придётся дать немного теории. Знаю, это занудно, но что поделать...

Проблемы на практике

Рекомендации

Итого

Публикации

Информация