Если следовать определению унаследованного кода, данному Майклом Фезерсом (каждый код, не покрытый тестами), то первое направление работы с некоторым унаследованным кодом, требующим обновления, — поместить его в тестовую обвязку (написать для него тест). Но это часто легче сказать, чем сделать. Просто создать экземпляр (устаревшего) класса в тесте может быть на удивление сложно из-за того, как он обрабатывает свои зависимости.

Давайте рассмотрим две наиболее часто встречающиеся проблемы и способы их решения.

Случай с раздражающим параметром

Скажем, мы создаем приложение для интернет-магазина. Чтобы рассчитать цену продукта, нам нужно применить некоторую бизнес-логику (скидки, ваучеры…) и учесть НДС (налог), который предоставляется некоторым внешним сервисом:

class CalculatePrice
{
	public function __construct(private VatDotComClient $vatProvider)
	{
	}

	public function calculate(Product $product)
	{
		$taxRate = $this->vatProvider->getRate($product->countryCode());
		// some business logic to calculate price
	}
}

public function itAppliesTheTaxRate()
{
	$calculateTax = new CalculatePrice(
		new VatDotComClient('api-key', 'secret')
	);
        // ...
}

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

Что, если мы создадим какой-нибудь фиктивный НДС-клиент, возвращающий некоторые данные, которые мы контролируем (вместо того, чтобы общаться с каким-то реальным провайдером по сети). Затем мы могли бы использовать этого фиктивного провайдера в нашем тесте и настоящего в производственном коде. Звучит неплохо, но наш сервис зависит от (реального) VatDotComClient. Раздражает, да?

Чтобы обойти это, мы можем применить рефакторинг Extract Interface . Во-первых, мы создаем интерфейс (на основе VatDotComClient):

interface VatProvider
{
	public function getRate(string $countryCode): float;
}

class CalculatePrice
{
	public function __construct(private VatProvider $vatProvider)
	{
	}

	public function calculate(Product $product)
	{
		$taxRate = $this->vatProvider->getRate($product->countryCode());
		// some business logic to calculate price
	}
}

class TestProvider implements VatProvider
{
	public function __construct(private float $rate)
	{
	}

	public function getRate(string $countryCode)
	{
		return $this->rate;
	}
}

public function itAppliesTheTaxRate()
{
	$calculateTax = new CalculatePrice(
		new TestProvider(0.25)
	);

	// ... Assert price what expected (with 0.25 tax rate)
}

Случай скрытой зависимости

Теперь, когда мы можем рассчитывать цены на наши продукты и люди их покупают, нам также необходимо обрабатывать их платежи. Скажем, у нас есть такой сервис:

class ProcessPayment
{
	public function __construct()
	{
		// ...
	}

	public function process(Payment $payment)
	{
		// ...
	}
}

public function itRecordsThePayment()
{
	$payment = new Payment(340, 'EUR', 12);

	$processPayment = new ProcessPayment();
	$processpayments->process($payment);
	
	// ... Assert stuff
}

Что ж, при ближайшем рассмотрении нашего ProcessPaymentсервиса мы видим, что он имеет зависимость от Mailerкласса, но скрыт в конструкторе (или в каком-то методе), и где-то между всей бизнес-логикой был вызов к нему для отправки электронного письма.

class ProcessPayment
{
	public function __construct()
	{
		// some code
		$this->mailer = new Mailer('api-key', 'secret');
		// some code
	}

	public function process(Payment $payment)
	{
		// ...
	
		$this->mailer->send($payment->receiver(), new PaymentNotificationMessage($payment)):
		
	}
}

class ProcessPayment
{
	public function __construct(Mailer $mailer)
	{
		$this->mailer = $mailer;
	}

	public function process(Payment $payment)
	{
		// ...
	}
}

Синергия тестирования и хорошего дизайна

Если вы посмотрите на наш код после рефакторинга, он теперь использует хорошо известный принцип хорошего дизайна — Dependency Injection . Кроме того, наш сервис больше не зависит от конкретной реализации, а зависит от абстракции (еще один принцип хорошего дизайна). Это позволяет нам обмениваться этими конкретными реализациями ( шаблон разработки стратегии ). Таким образом, теперь не только наш код стал более тестируемым, но и наш дизайн также улучшился.

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

Вот почему вы должны стремиться использовать разработку через тестирование при разработке нового кода. Что касается наследства, если вам нужны дополнительные советы по работе с ним, прочтите книгу Майкла Фезерса « Эффективная работа с устаревшим кодом », чтобы получить дополнительные советы и рекомендации.