Разница между использованием юнит-теста и обычным тестированием в Python3

Question

Какая разница между использованием юнит-тестов и обычных тестов?

Под normal tests Я имею в виду, используя выражение if, например, чтобы определить, равен ли расчет желаемому ответу, если он возвращает false, мы можем повысить AssertionError

Answer 1

Давайте в качестве примера рассмотрим простой фрагмент кода:

def square(a):
   return a*a;

Тесты, направленные на поиск ошибок в этой функции в отдельности, являются юнит-тестами. Это не зависит от того, как вы на самом деле их реализуете: если вы просто напишите оператор if, например if (square(3) != 9), и поднимите AssertionError, как вы говорите, тогда это модульный тест. Если вместо этого вы реализуете тот же тест, используя unittest, вызывая assertEqual, то это также является юнит-тестом.

Другими словами, используете ли вы (так называемый) юнит-тест Framework не является критерием того, являются ли ваши тесты юнит-тестами или нет. Фактически, несмотря на названия структур ('unittest' в Python, 'JUnit' в Java, ...), эти инфраструктуры могут использоваться для модульных тестов, а также для других тестов, таких как интеграция. тесты. Поэтому названия этих фреймворков немного вводят в заблуждение.

Так много для первоначального вопроса о разнице между юнит-тестами и обычными тестами. В одном из комментариев вы поясняете, что на самом деле хотите знать, что лучше: использовать или не использовать тестовую среду. И ответ ясен: определенно go для тестового фреймворка.

После написания только нескольких тестов «вручную», то есть без тестового фреймворка, вы увидите, что существует много дублирование в вашем тестовом коде: вы сравниваете результаты с if - это не так уж отличается. Но затем, в случае успеха вы пишете какое-то «пройденное» сообщение с именем теста, в случае неудачи вы пишете «неудачные» сообщения, опять же с именем теста и в этом случае также с некоторой дополнительной информацией о том, что было на самом деле и каков был ожидаемый результат. И - вы думали о том, что тестируемый код завершается с исключением? Итак, вам также нужно обернуть его блоком try / catch, чтобы непредвиденные исключения приводили к «неудачному» результату, опять же с некоторой полезной информацией о диагностике c.

И так далее ... Все Об этом и многом другом заботятся тестовые рамки для вас.

Answer 2

Для контроля качества. Если вы кодируете приложение под названием «app1» с функцией f1 и другой функцией f2 (f2 использует f1) внутри вашей собственной библиотеки

Без модульного теста: вы можете внести изменения в функцию f1, протестировав его, это будет работать в f2, но вы не заметите, что в вашей программе "app0", которую вы написали 2 недели go, это сделает вас приложением cra sh, потому что в вашем старом приложении "app0" у вас есть функция f3, а f3 также используя f1 ....

С модульным тестом: вы можете обнаружить этот тип неприятной ошибки, потому что тест для функции f3 больше не будет проходить, и ваша IDE сообщит вам об этом, когда вы измените функцию f1 в "app1"

Надеюсь, это имеет смысл (engli sh не мой родной язык)

Answer 3

Исходя из вашего вопроса, вы предполагаете, что существует два вида тестов: модульные тесты и нормальный тест . На самом деле, существует множество типов тестов. Модульный тест является одним из них. Вы можете прочитать здесь другие виды тестов.

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

# Your Function
def my_sum_function(x,y):
    return(x+y)

# Your Unit Test Function
def test_sum():
    assert my_sum_function([1, 2]) == 3, "Should be 6"

Не только для Python, но и для всех логических языков программирования c, стоящих за тестом, одинаковы.