commit 05ed2619457dea473828d9adb226665354a6bce0
from: Sergey Bronnikov <estetus@gmail.com>
via: Sergey Bronnikov <sergeyb@tarantool.org>
date: Fri Aug 02 19:03:36 2024 UTC

tests: update

commit - 6d73a631a6d1197eb654de06d001f45282fb9c16
commit + 05ed2619457dea473828d9adb226665354a6bce0
blob - 7f3e1c7aeba4e698b228eabbed6b21e6560cd5c3
blob + fa42293e1dca16558dfde4971a083f9e126a7385
--- tests/tarantool_datetime_new.lua
+++ tests/tarantool_datetime_new.lua
@@ -11,35 +11,6 @@
     https://github.com/dateutil/dateutil/blob/master/tests/test_tz.py
     https://github.com/Zac-HD/stdlib-property-tests/blob/master/tests/test_datetime.py
 
-датой и временем - datetime. В этом типе таится много нюансов: високосные
-года и секунда, таймзоны, DST (перевод часов на зимнее и летнее время). Из-за
-високосной секунды может быть время 23:59:60 и даже 23:59:61, 29 февраля
-бывает только в високосный год, причем иногда переход на DST может
-происходить два раза в год. С этим типом связано какое-то невероятное
-количество ошибок. Я даже писал заметку про баг в Excel, там до сих пор для
-совместимости с предыдущими версиями 1900-й год считается високосным, хотя он
-не високосный. Одно время Microsoft выпускала музыкальный плеер Zune и там
-тоже была проблема расчёта високосного года - 31 декабря в високосный год все
-плееры выключились.
-
-С таким количеством деталей идея применить тестирование с помощью свойств
-кажется очень заманчивой - генерировать тестовые примеры на всём диапазоне и
-проверять соответствие спецификации. Но я пересмотрел тесты для реализации
-datetime в Python и Go и всё тестирование там строится вокруг конкретных
-примеров. Хотя нет, вру, автор Hypothesis писал в своём блоге про тестирование
-парсинга даты из строки с помощью roundtrip - если напечатать дату в заданном
-формате в строку и распарсить её с тем же форматом, то результат должен
-совпасть с первоначальной датой. Но roundtrip это слишком просто, хотя тот же
-автор Hypothesis нашел с таким тестом проблему в базовой библиотеке Python. И
-автор книги Software testing: Craftsman approach разбирал тестирование функции
-NextDate().
-
-Несколько типов багов: переполнение, неверная арифметика, парсинг дат из строк.
-Those that lead to error conditions, such as exceptions, error return codes,
-uninitialized variables, or endless loops
-Those that lead to incorrect data, such as off-by-one problems in range
-queries or aggregation
-
 "datetime.parse_date"
 "datetime.now"
 "datetime.interval"
blob - ba9f577ac42ebc494a18ea0f7098bc30cb03e72f
blob + 23e1449d0bac37aa83ab07b905639ec28556079a
--- tests/tarantool_msgpack_itv.lua
+++ tests/tarantool_msgpack_itv.lua
@@ -34,21 +34,10 @@ local function TestOneInput(buf)
     assert(itv == res)
 end
 
-if arg[1] then
-    local testcase = io.open(arg[1]):read("*all")
-    TestOneInput(testcase)
-    os.exit()
-end
-
-local script_path = debug.getinfo(1).source:match("@?(.*/)")
-
 local args = {
     print_pcs = 1,
-    corpus = script_path .. "tarantool-corpus/msgpack_decode",
-    dict = script_path .. "tarantool-corpus/msgpack_decode.dict",
     max_len = 4096,
     artifact_prefix = "msgpack_msgpack_itv_",
     max_total_time = 60,
-    print_final_stats = 1,
 }
 luzer.Fuzz(TestOneInput, nil, args)
blob - b8b622936e61b08f392d2803f9e04c3991133849
blob + 13ffb3073283358745c8d1758440b7cc9c2d98ad
--- tests/tarantool_stdio.lua
+++ tests/tarantool_stdio.lua
@@ -24,22 +24,11 @@ local function TestOneInput(buf)
     ph:close()
 end
 
-if arg[1] then
-    local fh = io.open(arg[1])
-    local testcase = fh:read("*all")
-    TestOneInput(testcase)
-    os.exit()
-end
-
-local script_path = debug.getinfo(1).source:match("@?(.*/)")
-
 local args = {
     max_len = 4096,
     print_pcs = 1,
     detect_leaks = 1,
-    corpus = script_path .. "tarantool-corpus/stdio",
     artifact_prefix = "stdio_",
     max_total_time = 60,
-    print_final_stats = 1,
 }
 luzer.Fuzz(TestOneInput, nil, args)
blob - 68121c190a8312f2b4f7ca01e2dbf0c0a289d67f (mode 644)
blob + /dev/null
--- tests/tarantool_string_byte.lua
+++ /dev/null
@@ -1,19 +0,0 @@
-local luzer = require("luzer")
-
-local function TestOneInput(buf)
-    local fdp = luzer.FuzzedDataProvider(buf)
-    local b = fdp:consume_string(1)
-    if #b ~= 0 then
-        local char_code = string.byte(b)
-        assert(type(char_code) == "number")
-        local byte = string.char(char_code)
-        assert(byte == b)
-    end
-end
-
-local args = {
-    max_len = 4096,
-    artifact_prefix = "string_byte",
-    max_total_time = 60,
-}
-luzer.Fuzz(TestOneInput, nil, args)
blob - d63a419cffda6a79e6c3c60bda51eab368305d10
blob + 93f86868b46c8e43d2392321c157a573336018d8
--- tests/tarantool_uri_escape.lua
+++ tests/tarantool_uri_escape.lua
@@ -14,6 +14,5 @@ local args = {
     max_len = 1024,
     artifact_prefix = "uri_escape_",
     max_total_time = 60,
-    print_final_stats = 1,
 }
 luzer.Fuzz(TestOneInput, nil, args)