github-mirrors/VictoriaMetrics
1
0
Fork 0
mirror of https://github.com/VictoriaMetrics/VictoriaMetrics.git synced 2024-11-21 14:44:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
VictoriaMetrics/app/vmctl/stepper/split_test.go

374 lines
8 KiB
Go
Raw Normal View History

vmctl: implement support of chunking data for vm-native export (#3044) vmctl: implement support of chunking data for vm-native export process See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/2733
2022-09-06 07:09:34 +00:00
package stepper
import (
"reflect"
"testing"
"time"
)
type testTimeRange []string
func mustParseDatetime(t string) time.Time {
result, err := time.Parse(time.RFC3339, t)
if err != nil {
panic(err)
}
return result
}
app/vmctl: switch from table-driven tests to f-tests This simplifies debugging tests and makes the test code more clear and concise. See https://itnext.io/f-tests-as-a-replacement-for-table-driven-tests-in-go-8814a8b19e9e While at is, consistently use t.Fatal* instead of t.Error* across tests, since t.Error* requires more boilerplate code, which can result in additional bugs inside tests. While t.Error* allows writing logging errors for the same, this doesn't simplify fixing broken tests most of the time. This is a follow-up for a9525da8a405b4bd36040ff5aeabc28f9c7a20a6
2024-07-12 06:59:31 +00:00
func TestSplitDateRange_Failure(t *testing.T) {
f := func(startStr, endStr, granularity string) {
t.Helper()
start := mustParseDatetime(startStr)
end := mustParseDatetime(endStr)
_, err := SplitDateRange(start, end, granularity, false)
if err == nil {
t.Fatalf("expecting non-nil result")
}
app/vmctl: enable range steps in reverse order (#5444) See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/5376
2023-12-12 12:05:44 +00:00
}
app/vmctl: switch from table-driven tests to f-tests This simplifies debugging tests and makes the test code more clear and concise. See https://itnext.io/f-tests-as-a-replacement-for-table-driven-tests-in-go-8814a8b19e9e While at is, consistently use t.Fatal* instead of t.Error* across tests, since t.Error* requires more boilerplate code, which can result in additional bugs inside tests. While t.Error* allows writing logging errors for the same, this doesn't simplify fixing broken tests most of the time. This is a follow-up for a9525da8a405b4bd36040ff5aeabc28f9c7a20a6
2024-07-12 06:59:31 +00:00
// validates start is before end
f("2022-02-01T00:00:00Z", "2022-01-01T00:00:00Z", StepMonth)
// validates granularity value
f("2022-01-01T00:00:00Z", "2022-02-01T00:00:00Z", "non-existent-format")
app/vmctl: enable range steps in reverse order (#5444) See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/5376
2023-12-12 12:05:44 +00:00
}
app/vmctl: switch from table-driven tests to f-tests This simplifies debugging tests and makes the test code more clear and concise. See https://itnext.io/f-tests-as-a-replacement-for-table-driven-tests-in-go-8814a8b19e9e While at is, consistently use t.Fatal* instead of t.Error* across tests, since t.Error* requires more boilerplate code, which can result in additional bugs inside tests. While t.Error* allows writing logging errors for the same, this doesn't simplify fixing broken tests most of the time. This is a follow-up for a9525da8a405b4bd36040ff5aeabc28f9c7a20a6
2024-07-12 06:59:31 +00:00
func TestSplitDateRange_Success(t *testing.T) {
f := func(startStr, endStr, granularity string, resultExpected []testTimeRange) {
t.Helper()
start := mustParseDatetime(startStr)
end := mustParseDatetime(endStr)
result, err := SplitDateRange(start, end, granularity, false)
if err != nil {
t.Fatalf("SplitDateRange() error: %s", err)
}
var testExpectedResults [][]time.Time
for _, dr := range resultExpected {
testExpectedResults = append(testExpectedResults, []time.Time{
mustParseDatetime(dr[0]),
mustParseDatetime(dr[1]),
})
}
if !reflect.DeepEqual(result, testExpectedResults) {
t.Fatalf("unexpected result\ngot\n%v\nwant\n%v", result, testExpectedResults)
}
app/vmctl: enable range steps in reverse order (#5444) See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/5376
2023-12-12 12:05:44 +00:00
}
app/vmctl: switch from table-driven tests to f-tests This simplifies debugging tests and makes the test code more clear and concise. See https://itnext.io/f-tests-as-a-replacement-for-table-driven-tests-in-go-8814a8b19e9e While at is, consistently use t.Fatal* instead of t.Error* across tests, since t.Error* requires more boilerplate code, which can result in additional bugs inside tests. While t.Error* allows writing logging errors for the same, this doesn't simplify fixing broken tests most of the time. This is a follow-up for a9525da8a405b4bd36040ff5aeabc28f9c7a20a6
2024-07-12 06:59:31 +00:00
// month chunking
f("2022-01-03T11:11:11Z", "2022-03-03T12:12:12Z", StepMonth, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-31T23:59:59.999999999Z",
},
{
"2022-02-01T00:00:00Z",
"2022-02-28T23:59:59.999999999Z",
},
{
"2022-03-01T00:00:00Z",
"2022-03-03T12:12:12Z",
app/vmctl: enable range steps in reverse order (#5444) See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/5376
2023-12-12 12:05:44 +00:00
},
app/vmctl: switch from table-driven tests to f-tests This simplifies debugging tests and makes the test code more clear and concise. See https://itnext.io/f-tests-as-a-replacement-for-table-driven-tests-in-go-8814a8b19e9e While at is, consistently use t.Fatal* instead of t.Error* across tests, since t.Error* requires more boilerplate code, which can result in additional bugs inside tests. While t.Error* allows writing logging errors for the same, this doesn't simplify fixing broken tests most of the time. This is a follow-up for a9525da8a405b4bd36040ff5aeabc28f9c7a20a6
2024-07-12 06:59:31 +00:00
})
// daily chunking
f("2022-01-03T11:11:11Z", "2022-01-05T12:12:12Z", StepDay, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-04T11:11:11Z",
},
{
"2022-01-04T11:11:11Z",
"2022-01-05T11:11:11Z",
},
{
"2022-01-05T11:11:11Z",
"2022-01-05T12:12:12Z",
},
})
// hourly chunking
f("2022-01-03T11:11:11Z", "2022-01-03T14:14:14Z", StepHour, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-03T12:11:11Z",
},
{
"2022-01-03T12:11:11Z",
"2022-01-03T13:11:11Z",
},
{
"2022-01-03T13:11:11Z",
"2022-01-03T14:11:11Z",
},
{
"2022-01-03T14:11:11Z",
"2022-01-03T14:14:14Z",
},
})
// month chunking with one day time range
f("2022-01-03T11:11:11Z", "2022-01-04T12:12:12Z", StepMonth, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-04T12:12:12Z",
},
})
// month chunking with same day time range
f("2022-01-03T11:11:11Z", "2022-01-03T12:12:12Z", StepMonth, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-03T12:12:12Z",
},
})
// month chunking with one month and two days range
f("2022-01-03T11:11:11Z", "2022-02-03T00:00:00Z", StepMonth, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-31T23:59:59.999999999Z",
},
{
"2022-02-01T00:00:00Z",
"2022-02-03T00:00:00Z",
},
})
// week chunking with not full week
f("2023-07-30T00:00:00Z", "2023-08-05T23:59:59.999999999Z", StepWeek, []testTimeRange{
{
"2023-07-30T00:00:00Z",
"2023-08-05T23:59:59.999999999Z",
},
})
// week chunking with start of the week and end of the week
f("2023-07-30T00:00:00Z", "2023-08-06T00:00:00Z", StepWeek, []testTimeRange{
{
"2023-07-30T00:00:00Z",
"2023-08-06T00:00:00Z",
},
})
// week chunking with next one day week
f("2023-07-30T00:00:00Z", "2023-08-07T01:12:00Z", StepWeek, []testTimeRange{
{
"2023-07-30T00:00:00Z",
"2023-08-06T00:00:00Z",
},
{
"2023-08-06T00:00:00Z",
"2023-08-07T01:12:00Z",
},
})
// week chunking with month and not full week representation
f("2023-07-30T00:00:00Z", "2023-09-01T01:12:00Z", StepWeek, []testTimeRange{
{
"2023-07-30T00:00:00Z",
"2023-08-06T00:00:00Z",
},
{
"2023-08-06T00:00:00Z",
"2023-08-13T00:00:00Z",
},
{
"2023-08-13T00:00:00Z",
"2023-08-20T00:00:00Z",
},
{
"2023-08-20T00:00:00Z",
"2023-08-27T00:00:00Z",
},
{
"2023-08-27T00:00:00Z",
"2023-09-01T01:12:00Z",
},
})
}
func TestSplitDateRange_Reverse_Failure(t *testing.T) {
f := func(startStr, endStr, granularity string) {
t.Helper()
start := mustParseDatetime(startStr)
end := mustParseDatetime(endStr)
_, err := SplitDateRange(start, end, granularity, true)
if err == nil {
t.Fatalf("expecting non-nil error")
}
app/vmctl: enable range steps in reverse order (#5444) See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/5376
2023-12-12 12:05:44 +00:00
}
app/vmctl: switch from table-driven tests to f-tests This simplifies debugging tests and makes the test code more clear and concise. See https://itnext.io/f-tests-as-a-replacement-for-table-driven-tests-in-go-8814a8b19e9e While at is, consistently use t.Fatal* instead of t.Error* across tests, since t.Error* requires more boilerplate code, which can result in additional bugs inside tests. While t.Error* allows writing logging errors for the same, this doesn't simplify fixing broken tests most of the time. This is a follow-up for a9525da8a405b4bd36040ff5aeabc28f9c7a20a6
2024-07-12 06:59:31 +00:00
// validates start is before end
f("2022-02-01T00:00:00Z", "2022-01-01T00:00:00Z", StepMonth)
// validates granularity value
f("2022-01-01T00:00:00Z", "2022-02-01T00:00:00Z", "non-existent-format")
}
func TestSplitDateRange_Reverse_Success(t *testing.T) {
f := func(startStr, endStr, granularity string, resultExpected []testTimeRange) {
t.Helper()
start := mustParseDatetime(startStr)
end := mustParseDatetime(endStr)
result, err := SplitDateRange(start, end, granularity, true)
if err != nil {
t.Fatalf("SplitDateRange() error: %s", err)
}
var testExpectedResults [][]time.Time
for _, dr := range resultExpected {
testExpectedResults = append(testExpectedResults, []time.Time{
mustParseDatetime(dr[0]),
mustParseDatetime(dr[1]),
})
}
if !reflect.DeepEqual(result, testExpectedResults) {
t.Fatalf("unexpected result\ngot\n%v\nwant\n%v", result, testExpectedResults)
}
vmctl: implement support of chunking data for vm-native export (#3044) vmctl: implement support of chunking data for vm-native export process See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/2733
2022-09-06 07:09:34 +00:00
}
app/vmctl: switch from table-driven tests to f-tests This simplifies debugging tests and makes the test code more clear and concise. See https://itnext.io/f-tests-as-a-replacement-for-table-driven-tests-in-go-8814a8b19e9e While at is, consistently use t.Fatal* instead of t.Error* across tests, since t.Error* requires more boilerplate code, which can result in additional bugs inside tests. While t.Error* allows writing logging errors for the same, this doesn't simplify fixing broken tests most of the time. This is a follow-up for a9525da8a405b4bd36040ff5aeabc28f9c7a20a6
2024-07-12 06:59:31 +00:00
// month chunking
f("2022-01-03T11:11:11Z", "2022-03-03T12:12:12Z", StepMonth, []testTimeRange{
{
"2022-03-01T00:00:00Z",
"2022-03-03T12:12:12Z",
},
{
"2022-02-01T00:00:00Z",
"2022-02-28T23:59:59.999999999Z",
},
{
"2022-01-03T11:11:11Z",
"2022-01-31T23:59:59.999999999Z",
},
})
// daily chunking
f("2022-01-03T11:11:11Z", "2022-01-05T12:12:12Z", StepDay, []testTimeRange{
{
"2022-01-05T11:11:11Z",
"2022-01-05T12:12:12Z",
},
{
"2022-01-04T11:11:11Z",
"2022-01-05T11:11:11Z",
},
{
"2022-01-03T11:11:11Z",
"2022-01-04T11:11:11Z",
},
})
// hourly chunking
f("2022-01-03T11:11:11Z", "2022-01-03T14:14:14Z", StepHour, []testTimeRange{
{
"2022-01-03T14:11:11Z",
"2022-01-03T14:14:14Z",
},
{
"2022-01-03T13:11:11Z",
"2022-01-03T14:11:11Z",
},
{
"2022-01-03T12:11:11Z",
"2022-01-03T13:11:11Z",
},
{
"2022-01-03T11:11:11Z",
"2022-01-03T12:11:11Z",
},
})
// month chunking with one day time range
f("2022-01-03T11:11:11Z", "2022-01-04T12:12:12Z", StepMonth, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-04T12:12:12Z",
},
})
// month chunking with same day time range
f("2022-01-03T11:11:11Z", "2022-01-03T12:12:12Z", StepMonth, []testTimeRange{
{
"2022-01-03T11:11:11Z",
"2022-01-03T12:12:12Z",
},
})
// month chunking with one month and two days range
f("2022-01-03T11:11:11Z", "2022-02-03T00:00:00Z", StepMonth, []testTimeRange{
{
"2022-02-01T00:00:00Z",
"2022-02-03T00:00:00Z",
},
{
"2022-01-03T11:11:11Z",
"2022-01-31T23:59:59.999999999Z",
},
})
// week chunking with not full week
f("2023-07-30T00:00:00Z", "2023-08-05T23:59:59.999999999Z", StepWeek, []testTimeRange{
{
"2023-07-30T00:00:00Z",
"2023-08-05T23:59:59.999999999Z",
},
})
// week chunking with start of the week and end of the week
f("2023-07-30T00:00:00Z", "2023-08-06T00:00:00Z", StepWeek, []testTimeRange{
{
"2023-07-30T00:00:00Z",
"2023-08-06T00:00:00Z",
},
})
// week chunking with next one day week
f("2023-07-30T00:00:00Z", "2023-08-07T01:12:00Z", StepWeek, []testTimeRange{
{
"2023-08-06T00:00:00Z",
"2023-08-07T01:12:00Z",
},
{
"2023-07-30T00:00:00Z",
"2023-08-06T00:00:00Z",
},
})
// week chunking with month and not full week representation
f("2023-07-30T00:00:00Z", "2023-09-01T01:12:00Z", StepWeek, []testTimeRange{
{
"2023-08-27T00:00:00Z",
"2023-09-01T01:12:00Z",
},
{
"2023-08-20T00:00:00Z",
"2023-08-27T00:00:00Z",
},
{
"2023-08-13T00:00:00Z",
"2023-08-20T00:00:00Z",
},
{
"2023-08-06T00:00:00Z",
"2023-08-13T00:00:00Z",
},
{
"2023-07-30T00:00:00Z",
"2023-08-06T00:00:00Z",
},
})
vmctl: implement support of chunking data for vm-native export (#3044) vmctl: implement support of chunking data for vm-native export process See https://github.com/VictoriaMetrics/VictoriaMetrics/issues/2733
2022-09-06 07:09:34 +00:00
}
Reference in a new issue Copy permalink