Объясните юнит тестирование пожалуйста

Question

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

Теперь при тестировании я хотел бы знать такие вещи, как: находит ли поиск первый элемент, последний элемент и другие элементы?Правильно ли поиск сравнивает символы Юникода.Обрабатывает ли поиск символы и другие «болезненные» символы.Будет ли модульное тестирование покрывать это, или я пропускаю это?Как бы вы написали модульные тесты для моего бинарного поиска?

function search(collection, value){
 var start = 0, end = collection.length - 1, mid;
 while (start <= end) {
  mid = start + ((end - start) / 2);
  if (value == collection[mid])
   return mid;
  if (collection[mid] < value)
   end = mid - 1;
  else
       start = mid + 1;
 }
 return mid;
}

Код Psuedo для модульных тестов был бы прекрасен.

Итак, мы могли бы иметь:

function testFirst(){
 var collection = ['a','b','c','x','y','z'],first = 'a', findex = 0;
 assert(seach(collection,first),findex);
}
function testLast(){
 var collection = ['a','b','c','x','y','z'], last = 'z', lindex = 5;
 assert(seach(collection,last),lindex);
}

Answer 1

Нет, вы не пропустите это, это то, что модульное тестирование предназначено для вас. У вас есть правильная идея, проверяя хорошие и плохие входные данные, граничные случаи и т. Д. Вам нужен один тест для каждого условия. Тест установит все предварительные условия, а затем подтвердит, что ваш расчет (или что бы то ни было) соответствует вашим ожиданиям

Answer 2

Вы правы в своих ожиданиях модульного тестирования;это очень много о проверке и проверке ожидаемого поведения.

Одно значение, которое, я думаю, многие упускают из виду при модульном тестировании, это то, что его значение увеличивается со временем.Когда я пишу кусок кода и пишу модульный тест, я в основном только что проверил, что код делает то, что, как я думаю, должен, что он не дает ошибок в любых способах, которые я выбрал для проверки, и т. Д. Это хорошовещи, но они имеют ограниченную ценность, потому что они выражают знание, которое вы имеете о системе в то время;они не могут помочь вам с вещами, о которых вы не знаете (есть ли в моем алгоритме хитрая ошибка, о которой я не знаю и не собирался проверять?).

Реальная ценностьмодульных тестов, на мой взгляд, это ценность, которую они получают с течением времени.Это значение принимает две формы;значение документации и значение проверки.

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

Другое значение - это проверка;поскольку код живет в проектах, все подвергается рефакторингу, изменению и изменению.Модульные тесты обеспечивают проверку того, что компонент, который, по вашему мнению, работал одним способом, продолжает работать таким же образом.Это может иметь неоценимое значение, помогая находить ошибки, которые проникают в проекты.Например, изменение решения для базы данных иногда может быть прозрачным, но иногда эти изменения могут вызвать неожиданные изменения в работе некоторых вещей;модульное тестирование компонентов, которые зависят от вашего ORM, может выявить критические тонкие изменения в базовом поведении.Это действительно полезно, когда у вас есть кусок кода, который отлично работал в течение многих лет, и никто не думает рассматривать его потенциальную роль в сбое;Эти типы ошибок могут найти ОЧЕНЬ много времени, потому что последнее место, которое вы будете искать, находится в компоненте, который был надежным в течение очень долгого времени.Модульное тестирование обеспечивает проверку этой «твердости породы».

Answer 3

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

В вашем случае настройка 'collection' с некоторыми конкретными значениями (или без значений) является настройкойпредварительные условия.

При вызове метода поиска с определенным параметром выполняется тестируемый код.

Проверка того, что значение, возвращаемое вашим методом, соответствует ожидаемому шагу подтверждения.

Дайте этим трем вещам имя, которое описывает, что вы пытаетесь сделать (DoesTheSearchMethodFailIfCollectionIsEmpty), и вуаля, у вас есть модульный тест.