Этот блок-тест является чрезмерным?

Question

Учитывая следующее SUT, считаете ли вы этот модульный тест ненужным?

** edit: мы не можем предположить, что имена будут совпадать, поэтому отражение не сработает.

** edit 2: на самом деле этот класс будет реализовывать интерфейс IMapper, и на уровне бизнес-логики приложения будет проводиться полномасштабное поведенческое (фиктивное) тестирование. этот тест просто является самым низким уровнем тестирования, который должен быть основан на состоянии. Я сомневаюсь, действительно ли этот тест необходим, потому что тестовый код практически идентичен самому исходному коду, и исходя из реального опыта, я не вижу, как этот модульный тест облегчает обслуживание приложения.

//SUT
public class Mapper
{
  public void Map(DataContract from, DataObject to)
  {
    to.Value1 = from.Value1;
    to.Value2 = from.Value2;
    ....
    to.Value100 = from.Value100;
  }
}

//Unit Test
public class MapperTest()
{
   DataContract contract = new DataContract(){... } ;
   DataObject do = new DataObject(){...};
   Mapper mapper = new Mapper();
   mapper.Map(contract, do);
   Assert.AreEqual(do.Value1, contract.Value1);
   ...
   Assert.AreEqual(do.Value100, contract.Value100);

}

Answer 1

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

Однако, если у вас есть класс с 100 свойствами с именем ValueXXX, то вам лучше использовать массив или список.

Answer 2

я бы поставил под сомнение саму конструкцию, а не необходимость проверять ее

[отражение будет гораздо меньше кода]

Answer 3

Это не чрезмерно. Я уверен, что не уверен, что он полностью фокусируется на том, что вы хотите проверить.

"В соответствии со строгим определением, для целей QA, провал UnitTest подразумевает только одну единицу. Вы точно знаете, где искать, чтобы найти ошибку."

Сила модульного теста заключается в наличии известного правильного результирующего состояния, в центре внимания должны быть значения, назначенные DataContract. Это те границы, которые мы хотим раздвинуть. Чтобы гарантировать, что все возможные значения для DataContract могут быть успешно скопированы в DataObject. DataContract должен быть заполнен краевыми значениями.

PS. Дэвид Кемп прав: 100 хорошо разработанных тестов были бы наиболее верны концепции модульного тестирования.

Примечание: Для этого теста мы должны предположить, что DataContract заполняется идеально при сборке (для этого требуются отдельные тесты).

Answer 4

Было бы лучше, если бы вы могли тестировать на более высоком уровне, то есть бизнес-логике, которая требует от вас создания функции Mapper.Map ().

Answer 5

Не исключительно.

Я согласен, что код выглядит странно, но это говорит:

Прелесть модульного тестирования в том, что когда-то он сделан, он существует навсегда, поэтому, если кто-то по какой-либо причине решит изменить эту реализацию на что-то более «умное», тест должен пройти, так что ничего страшного.

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

Answer 6

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