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

Во время моей первой работы — годовой оплачиваемой стажировки — я поначалу разочаровался в необходимости изучать основные шаблоны объектно-ориентированного программного обеспечения. На сегодняшний день я все еще нахожусь в большом лагере тех, кто разочаровался в ООП и его религиозности. FizzBuzz Enterprise Edition — это то, что после многих лет работы в отрасли знакомо почти всем бэкенд-инженерам. В конце концов, разумные предложения впитались, заметно избежав проблем и ловушек. Это было в первую очередь учение о разделении концернов на ТВЕРДЫЕ, СУХИЕ и т. д.; а также шаблоны для конкретных технологий, такие как WinForms MVP (я скучаю по тем временам). Их преимущества были очевидны, длительны и не вызывали сожаления или нерешительности.

Моя вторая работа была другой историей. Меня любезно взяли на борт в качестве разработчика полного стека без предварительного знания ASP.NET MVC, WebApi, Blazor и т. д. На самом деле, первые несколько недель я мигрировал исключительно на Webpack, как человек, который когда-либо использовал только рукописный Java‹скрипт›! Я помню, что для изучения MVC основным препятствием было то, что хотя это звучит как шаблон, и Microsoft даже рекламирует его как Шаблон ASP.NET MVC, на самом деле это замаскированный зверь. как продукт, замаскированный под шаблон. Это всегда выводило меня из себя, когда я искал логику в чем-то, что представляло собой мешанину произвольных или бессвязных рассуждений. И все же во время моего пребывания в их команде была более зловещая чума.

Как и в предыдущей роли, охват модульными тестами был равен 0%. Интеграционные тесты имели смысл, тестирование черного ящика имело смысл, а специальный член отдела контроля качества в нашей команде разработчиков был благословением. Но зачем мне писать код для тестирования… другого кода? Мне потребовалось смущающе много времени, чтобы понять (и только через демонстрацию!), что модульное тестирование предназначено для защиты от регрессий, которые в противном случае вам пришлось бы обнаруживать вручную. Это для вас или члена команды, который возвращается к коду через десять минут или десять лет и пытается сделать быстрое исправление или чувствует, что у него хорошо получается подтягивать некоторую логику. Для меня наиболее ценной формой тестирования является визуальное регрессионное тестирование, такое как Chromatic, хотя написание модульных тестов, безусловно, помогает понять, для чего предназначен их код.

Я узнал об этом во время своей третьей роли, у которой была довольно неглубокая кривая обучения — я уже работал с ASP.NET, CQRS, внедрением зависимостей и всевозможными абстракциями и слоями, которые до этого считал бессмысленными, пустой тратой времени, модными словечками. Оживать. Но была разница: 80% обязательного тестового покрытия с использованием Moq и AutoFixture. Именно тогда я понял, что не слышал полной истории об этих отраслевых практиках и, казалось бы, бесконечных слоях абстракции — это для тестируемости. Во вселенной, где модульное тестирование было всего лишь инопланетным набором инструментов, прикрепленным к IDE, у меня не было никакой надежды реализовать это. Что еще хуже, из-за отсутствия тестов и того, что нарушения стали более очевидными, отклонение от этих лучших практик вне трассы сделало их еще более пугающими и менее заметными.

Мораль истории? Наблюдайте за тем, как другие предприятия и профессионалы используют технологию, которую используете вы, и не игнорируйте модульное тестирование, если вы внедряете эти конкретные отраслевые практики. Даже 10 % покрытия тестами лучше, чем 0 %, для смягчения регрессий и понимания того, что Microsoft шепчет на ухо вашему менеджеру.