Юнит-тестирование в геймдеве при наличии сильных зависимостей

Есть класс TextureRegion2D, который представляет собой прямоугольный фрагмент текстуры и принимает в конструкторе экземпляр Texture2D текстуры, на которой расположен этот фрагмент.

public class TextureRegion2D
{
    public string Name { get; }
    public Texture2D Texture { get; }
    public TextureRegion2D(string name, Texture2D texture)
    {
        if (!string.IsNullOrEmpty(name))
            Name = name;
        else
            throw new ArgumentException("The name of the texture region can not be null or an empty string.", nameof(name));
        Texture = texture ?? throw new ArgumentNullException(nameof(texture));
    }
}

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

В качестве путей разрешения ситуации я вижу два пути:

1. Не тестировать конструкторы и методы данного класса вовсе. Что плохо, потому что в конструкторе присутствует логика проверки аргументов на валидность, которую хотелось бы покрыть тестами.

2. Создать базовый internal конструктор, который будут вызывать публичные, в котором можно будет параметрами отключить проверку тех или иных аргументов.

   internal TextureRegion2D(string name, Texture2D texture, bool checkName, bool checkTexture)
   {
       if (!checkName || (checkName && !string.IsNullOrEmpty(name)))
           Name = name;
       else
           throw new ArgumentException("The name of the texture region can not be null or an empty string.", nameof(name));
       if (!checkTexture || (checkTexture && texture != null))
           Texture = texture;
       else
           throw new ArgumentNullException(nameof(texture));
   }
   public TextureRegion2D(string name, Texture2D texture)
       : this(name, texture, true, true) { }
   

Каким путем лучше пойти в данной ситуации?

Обновлено: конкретно для данной ситуации нашел решение через инициализацю графического адаптера без создания экземпляра игры, но вопрос остается актуальным - как в общем случае тестировать методы, использующие типы из библиотек третьей стороны, но из-за своей атомарности не предполагающие разделения зависимостей с помощью паттерна фабрика или подобных ему?