Модульный тест для несуществующего универсального аргумента

Question

Мне интересно, как (или если мне нужно) протестировать определенное сценарий в моем коде, который включает в себя общую коллекцию.

Что у меня есть это:

// Function
private void Func(FieldInfo fieldInfo)
{
   if(fieldInfo.FieldType.IsGenericType)
   {
      // Only support List<> right now
      Type gen_type = fieldInfo.FieldType.GetGenericTypeDefinition();
      if(gen_type != typeof(List<>))
      {
         throw new 
            NotSupportedException("Only Generic List is supported at this time");
      }
      // Find the generic list type
      Type[] generic_types = fieldInfo.FieldType.GetGenericArguements();
      if(generic_types.Length <= 0)
      {
         throw new 
            NotSupportedException("Generic List type not found!");
      }
   }
}

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

Answer 1

Чтение страницы MSDN на Type.GetGenericArguments () , кажется, что метод когда-либо будет возвращать пустой массив только тогда, когда представленный тип не является универсальным типом. Поскольку вы знаете , что представленный здесь тип является универсальным типом (а именно, List или List <>), метод всегда будет возвращать либо T, либо объект типа, представляющий универсальный параметр, имеющий значение true для свойства IsGenericParameter.

В своем текущем состоянии массив generic_types никогда не должен быть пустым. Я бы сказал, нет, вам не нужно проверять его, независимо от того, говорите ли вы о модульном тесте или простом защитном заявлении, как в приведенном выше коде. Он не подходит для модульного теста, потому что сводится к одной из двух ситуаций: либо вы в конечном итоге тестируете фреймворк (который, как мы должны предполагать, уже тестировали Microsoft), либо вы заканчиваете тестированием внутренних деталей реализации вашего модульного теста , который является тестовым анти-паттерном. Для защитного заявления, вы просто не должны проверять ситуации, которые должны быть невозможны, если непосредственный код написан правильно. Подобные проверки во время выполнения должны быть зарезервированы для вещей, которые могут происходить во время выполнения в зависимости от среды, даже если непосредственный код верен.