mirror/ git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-30 00:56:08 +02:00
Code
git/t/t0500-progress-display.sh

312 lines
7.2 KiB
Bash
Raw Normal View History

Test the progress display 'progress.c' has seen a few fixes recently [1], and, unfortunately, some of those fixes required further fixes [2]. It seems it's time to have a few tests focusing on the subtleties of the progress display. Add the 'test-tool progress' subcommand to help testing the progress display, reading instructions from standard input and turning them into calls to the display_progress() and display_throughput() functions with the given parameters. The progress display is, however, critically dependent on timing, because it's only updated once every second or, if the toal is known in advance, every 1%, and there is the throughput rate as well. These make the progress display far too undeterministic for testing as-is. To address this, add a few testing-specific variables and functions to 'progress.c', allowing the the new test helper to: - Disable the triggered-every-second SIGALRM and set the 'progress_update' flag explicitly based in the input instructions. This way the progress line will be updated deterministically when the test wants it to be updated. - Specify the time elapsed since start_progress() to make the throughput rate calculations deterministic. Add the new test script 't0500-progress-display.sh' to check a few simple cases with and without throughput, and that a shorter progress line properly covers up the previously displayed line in different situations. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). [2] 1aed1a5f25 (progress: avoid empty line when breaking the progress line, 2019-05-19) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
#!/bin/sh
test_description='progress display'
. ./test-lib.sh
show_cr () {
tr '\015' Q | sed -e "s/Q/<CR>\\$LF/g"
}
test_expect_success 'simple progress display' '
cat >expect <<-\EOF &&
Working hard: 1<CR>
Working hard: 2<CR>
Working hard: 5<CR>
Working hard: 5, done.
EOF
cat >in <<-\EOF &&
update
progress 1
update
progress 2
progress 3
progress 4
update
progress 5
EOF
test-tool progress "Working hard" <in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'progress display with total' '
cat >expect <<-\EOF &&
Working hard: 33% (1/3)<CR>
Working hard: 66% (2/3)<CR>
Working hard: 100% (3/3)<CR>
Working hard: 100% (3/3), done.
EOF
cat >in <<-\EOF &&
progress 1
progress 2
progress 3
EOF
test-tool progress --total=3 "Working hard" <in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'progress display breaks long lines #1' '
sed -e "s/Z$//" >expect <<\EOF &&
Working hard.......2.........3.........4.........5.........6: 0% (100/100000)<CR>
Working hard.......2.........3.........4.........5.........6: 1% (1000/100000)<CR>
Working hard.......2.........3.........4.........5.........6: Z
10% (10000/100000)<CR>
100% (100000/100000)<CR>
100% (100000/100000), done.
EOF
cat >in <<-\EOF &&
progress 100
progress 1000
progress 10000
progress 100000
EOF
test-tool progress --total=100000 \
"Working hard.......2.........3.........4.........5.........6" \
<in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'progress display breaks long lines #2' '
Fix spelling errors in comments of testcases Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-05 18:07:24 +01:00
# Note: we do not need that many spaces after the title to cover up
Test the progress display 'progress.c' has seen a few fixes recently [1], and, unfortunately, some of those fixes required further fixes [2]. It seems it's time to have a few tests focusing on the subtleties of the progress display. Add the 'test-tool progress' subcommand to help testing the progress display, reading instructions from standard input and turning them into calls to the display_progress() and display_throughput() functions with the given parameters. The progress display is, however, critically dependent on timing, because it's only updated once every second or, if the toal is known in advance, every 1%, and there is the throughput rate as well. These make the progress display far too undeterministic for testing as-is. To address this, add a few testing-specific variables and functions to 'progress.c', allowing the the new test helper to: - Disable the triggered-every-second SIGALRM and set the 'progress_update' flag explicitly based in the input instructions. This way the progress line will be updated deterministically when the test wants it to be updated. - Specify the time elapsed since start_progress() to make the throughput rate calculations deterministic. Add the new test script 't0500-progress-display.sh' to check a few simple cases with and without throughput, and that a shorter progress line properly covers up the previously displayed line in different situations. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). [2] 1aed1a5f25 (progress: avoid empty line when breaking the progress line, 2019-05-19) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
# the last line before breaking the progress line.
sed -e "s/Z$//" >expect <<\EOF &&
Working hard.......2.........3.........4.........5.........6: 0% (1/100000)<CR>
Working hard.......2.........3.........4.........5.........6: 0% (2/100000)<CR>
Working hard.......2.........3.........4.........5.........6: Z
10% (10000/100000)<CR>
100% (100000/100000)<CR>
100% (100000/100000), done.
EOF
cat >in <<-\EOF &&
update
progress 1
update
progress 2
progress 10000
progress 100000
EOF
test-tool progress --total=100000 \
"Working hard.......2.........3.........4.........5.........6" \
<in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'progress display breaks long lines #3 - even the first is too long' '
Fix spelling errors in comments of testcases Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-05 18:07:24 +01:00
# Note: we do not actually need any spaces at the end of the title
Test the progress display 'progress.c' has seen a few fixes recently [1], and, unfortunately, some of those fixes required further fixes [2]. It seems it's time to have a few tests focusing on the subtleties of the progress display. Add the 'test-tool progress' subcommand to help testing the progress display, reading instructions from standard input and turning them into calls to the display_progress() and display_throughput() functions with the given parameters. The progress display is, however, critically dependent on timing, because it's only updated once every second or, if the toal is known in advance, every 1%, and there is the throughput rate as well. These make the progress display far too undeterministic for testing as-is. To address this, add a few testing-specific variables and functions to 'progress.c', allowing the the new test helper to: - Disable the triggered-every-second SIGALRM and set the 'progress_update' flag explicitly based in the input instructions. This way the progress line will be updated deterministically when the test wants it to be updated. - Specify the time elapsed since start_progress() to make the throughput rate calculations deterministic. Add the new test script 't0500-progress-display.sh' to check a few simple cases with and without throughput, and that a shorter progress line properly covers up the previously displayed line in different situations. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). [2] 1aed1a5f25 (progress: avoid empty line when breaking the progress line, 2019-05-19) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
# line, because there is no previous progress line to cover up.
sed -e "s/Z$//" >expect <<\EOF &&
Working hard.......2.........3.........4.........5.........6: Z
25% (25000/100000)<CR>
50% (50000/100000)<CR>
75% (75000/100000)<CR>
100% (100000/100000)<CR>
100% (100000/100000), done.
EOF
cat >in <<-\EOF &&
progress 25000
progress 50000
progress 75000
progress 100000
EOF
test-tool progress --total=100000 \
"Working hard.......2.........3.........4.........5.........6" \
<in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'progress display breaks long lines #4 - title line matches terminal width' '
cat >expect <<\EOF &&
Working hard.......2.........3.........4.........5.........6.........7.........:
25% (25000/100000)<CR>
50% (50000/100000)<CR>
75% (75000/100000)<CR>
100% (100000/100000)<CR>
100% (100000/100000), done.
EOF
cat >in <<-\EOF &&
progress 25000
progress 50000
progress 75000
progress 100000
EOF
test-tool progress --total=100000 \
"Working hard.......2.........3.........4.........5.........6.........7........." \
<in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
# Progress counter goes backwards, this should not happen in practice.
test_expect_success 'progress shortens - crazy caller' '
cat >expect <<-\EOF &&
Working hard: 10% (100/1000)<CR>
Working hard: 20% (200/1000)<CR>
Working hard: 0% (1/1000) <CR>
Working hard: 100% (1000/1000)<CR>
Working hard: 100% (1000/1000), done.
EOF
cat >in <<-\EOF &&
progress 100
progress 200
progress 1
progress 1000
EOF
test-tool progress --total=1000 "Working hard" <in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'progress display with throughput' '
cat >expect <<-\EOF &&
Working hard: 10<CR>
Working hard: 20, 200.00 KiB | 100.00 KiB/s<CR>
Working hard: 30, 300.00 KiB | 100.00 KiB/s<CR>
Working hard: 40, 400.00 KiB | 100.00 KiB/s<CR>
Working hard: 40, 400.00 KiB | 100.00 KiB/s, done.
EOF
cat >in <<-\EOF &&
throughput 102400 1000
update
progress 10
throughput 204800 2000
update
progress 20
throughput 307200 3000
update
progress 30
throughput 409600 4000
update
progress 40
EOF
test-tool progress "Working hard" <in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'progress display with throughput and total' '
cat >expect <<-\EOF &&
Working hard: 25% (10/40)<CR>
Working hard: 50% (20/40), 200.00 KiB | 100.00 KiB/s<CR>
Working hard: 75% (30/40), 300.00 KiB | 100.00 KiB/s<CR>
Working hard: 100% (40/40), 400.00 KiB | 100.00 KiB/s<CR>
Working hard: 100% (40/40), 400.00 KiB | 100.00 KiB/s, done.
EOF
cat >in <<-\EOF &&
throughput 102400 1000
progress 10
throughput 204800 2000
progress 20
throughput 307200 3000
progress 30
throughput 409600 4000
progress 40
EOF
test-tool progress --total=40 "Working hard" <in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'cover up after throughput shortens' '
cat >expect <<-\EOF &&
Working hard: 1<CR>
Working hard: 2, 800.00 KiB | 400.00 KiB/s<CR>
Working hard: 3, 1.17 MiB | 400.00 KiB/s <CR>
Working hard: 4, 1.56 MiB | 400.00 KiB/s<CR>
Working hard: 4, 1.56 MiB | 400.00 KiB/s, done.
EOF
cat >in <<-\EOF &&
throughput 409600 1000
update
progress 1
throughput 819200 2000
update
progress 2
throughput 1228800 3000
update
progress 3
throughput 1638400 4000
update
progress 4
EOF
test-tool progress "Working hard" <in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
test_expect_success 'cover up after throughput shortens a lot' '
cat >expect <<-\EOF &&
Working hard: 1<CR>
Working hard: 2, 1000.00 KiB | 1000.00 KiB/s<CR>
Working hard: 3, 3.00 MiB | 1.50 MiB/s <CR>
Working hard: 3, 3.00 MiB | 1024.00 KiB/s, done.
EOF
cat >in <<-\EOF &&
throughput 1 1000
update
progress 1
throughput 1024000 2000
update
progress 2
throughput 3145728 3000
update
progress 3
EOF
test-tool progress "Working hard" <in 2>stderr &&
show_cr <stderr >out &&
test_i18ncmp expect out
'
trace2: log progress time and throughput Rather than teaching only one operation, like 'git fetch', how to write down throughput to traces, we can learn about a wide range of user operations that may seem slow by adding tooling to the progress library itself. Operations which display progress are likely to be slow-running and the kind of thing we want to monitor for performance anyways. By showing object counts and data transfer size, we should be able to make some derived measurements to ensure operations are scaling the way we expect. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-12 23:44:20 +02:00
test_expect_success 'progress generates traces' '
cat >in <<-\EOF &&
throughput 102400 1000
update
progress 10
throughput 204800 2000
update
progress 20
throughput 307200 3000
update
progress 30
throughput 409600 4000
update
progress 40
EOF
GIT_TRACE2_EVENT="$(pwd)/trace.event" test-tool progress --total=40 \
"Working hard" <in 2>stderr &&
# t0212/parse_events.perl intentionally omits regions and data.
test-lib: test_region looks for trace2 regions From ff15d509b89edd4830d85d53cea3079a6b0c1c08 Mon Sep 17 00:00:00 2001 From: Derrick Stolee <dstolee@microsoft.com> Date: Mon, 11 Jan 2021 08:53:09 -0500 Subject: [PATCH 8/9] test-lib: test_region looks for trace2 regions Most test cases can verify Git's behavior using input/output expectations or changes to the .git directory. However, sometimes we want to check that Git did or did not run a certain section of code. This is particularly important for performance-only features that we want to ensure have been enabled in certain cases. Add a new 'test_region' function that checks if a trace2 region was entered and left in a given trace2 event log. There is one existing test (t0500-progress-display.sh) that performs this check already, so use the helper function instead. Note that this changes the expectations slightly. The old test (incorrectly) used two patterns for the 'grep' invocation, but this performs an OR of the patterns, not an AND. This means that as long as one region_enter event was logged, the test would succeed, even if it was not due to the progress category. More uses will be added in a later change. t6423-merge-rename-directories.sh also greps for region_enter lines, but it verifies the number of such lines, which is not the same as an existence check. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-23 22:07:08 +01:00
test_region progress "Working hard" trace.event &&
trace2: log progress time and throughput Rather than teaching only one operation, like 'git fetch', how to write down throughput to traces, we can learn about a wide range of user operations that may seem slow by adding tooling to the progress library itself. Operations which display progress are likely to be slow-running and the kind of thing we want to monitor for performance anyways. By showing object counts and data transfer size, we should be able to make some derived measurements to ensure operations are scaling the way we expect. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-12 23:44:20 +02:00
grep "\"key\":\"total_objects\",\"value\":\"40\"" trace.event &&
grep "\"key\":\"total_bytes\",\"value\":\"409600\"" trace.event
'
Test the progress display 'progress.c' has seen a few fixes recently [1], and, unfortunately, some of those fixes required further fixes [2]. It seems it's time to have a few tests focusing on the subtleties of the progress display. Add the 'test-tool progress' subcommand to help testing the progress display, reading instructions from standard input and turning them into calls to the display_progress() and display_throughput() functions with the given parameters. The progress display is, however, critically dependent on timing, because it's only updated once every second or, if the toal is known in advance, every 1%, and there is the throughput rate as well. These make the progress display far too undeterministic for testing as-is. To address this, add a few testing-specific variables and functions to 'progress.c', allowing the the new test helper to: - Disable the triggered-every-second SIGALRM and set the 'progress_update' flag explicitly based in the input instructions. This way the progress line will be updated deterministically when the test wants it to be updated. - Specify the time elapsed since start_progress() to make the throughput rate calculations deterministic. Add the new test script 't0500-progress-display.sh' to check a few simple cases with and without throughput, and that a shorter progress line properly covers up the previously displayed line in different situations. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). [2] 1aed1a5f25 (progress: avoid empty line when breaking the progress line, 2019-05-19) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
test_done