Llewellyn/exa
1
0
Fork 0
mirror of https://github.com/Llewellynvdm/exa.git synced 2024-09-28 13:19:01 +00:00
Code Issues Projects Releases Wiki Activity
437ac0ea60
exa/xtests/run.sh

91 lines
3.9 KiB
Bash
Raw Normal View History

Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
#!/bin/bash
set +xe
# The exa binary we want to run
exa="$HOME/target/debug/exa --colour=always"
# Directory containing our awkward testcase files
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
testcases=/testcases
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Directory containing existing test results to compare against
results=/vagrant/xtests
Protect xtests against the passage of time There was a problem with the Vagrant tests where the year 2016 was hard-coded in as the modified date. This had to be done to make the --long tests use the correct date format, which varies depending on whether the timestamp is in the current year. Unfortunately, time progresses [citation needed], and what was once 2016 is now 2017, so the date format changed and the tests broke. Because the Vagrantfile is just a Ruby script, we can look up the current year at runtime and use that instead. There’s also a check added to the test runner that makes sure none of the files are more than 365 days old, because if any are, then it’s time to update the timestamps (or it’s the last day of a leap year)
2017-04-28 18:26:57 +00:00
# Check that no files were created more than a year ago.
# Files not from the current year use a different date format, meaning
# that tests will fail until the VM gets re-provisioned.
sudo find $testcases -mtime +365 -printf "File %p has not been modified since %TY! Consider re-provisioning; tests will probably fail.\n"
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Long view tests
oops I think I took this off to see how the output was different. Which means there should really be a better way to check how the output is different, other than running the command and looking!
2017-04-29 10:03:43 +00:00
$exa $testcases/files -l | diff -q - $results/files_l || exit 1
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
$exa $testcases/files -lh | diff -q - $results/files_lh || exit 1
$exa $testcases/files -lhb | diff -q - $results/files_lhb || exit 1
$exa $testcases/files -lhB | diff -q - $results/files_lhb2 || exit 1
Only engage the view when there are files to show This changes the way that views are used to display the actual lists of files. It used to pass empty vectors to the view methods, which most of the time would not print anything because there are no files to list — except when there’s a header row which gets printed for no files. By not calling the view method at all when there’s nothing to print, exa won’t ever print extra things in the view unless it needs to for a file. This fixes #106 “Don’t print the header if the result set is empty”
2016-10-29 18:07:43 +00:00
$exa $testcases/attributes/dirs/empty-with-attribute -lh | diff -q - $results/empty || exit 1
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Grid view tests
COLUMNS=40 $exa $testcases/files | diff -q - $results/files_40 || exit 1
COLUMNS=80 $exa $testcases/files | diff -q - $results/files_80 || exit 1
COLUMNS=120 $exa $testcases/files | diff -q - $results/files_120 || exit 1
COLUMNS=160 $exa $testcases/files | diff -q - $results/files_160 || exit 1
COLUMNS=200 $exa $testcases/files | diff -q - $results/files_200 || exit 1
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Long grid view tests
COLUMNS=40 $exa $testcases/files -lG | diff -q - $results/files_lG_40 || exit 1
COLUMNS=80 $exa $testcases/files -lG | diff -q - $results/files_lG_80 || exit 1
COLUMNS=120 $exa $testcases/files -lG | diff -q - $results/files_lG_120 || exit 1
COLUMNS=160 $exa $testcases/files -lG | diff -q - $results/files_lG_160 || exit 1
COLUMNS=200 $exa $testcases/files -lG | diff -q - $results/files_lG_200 || exit 1
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# Attributes
$exa $testcases/attributes -l@T | diff -q - $results/attributes || exit 1
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
# UIDs and GIDs
$exa $testcases/passwd -lgh | diff -q - $results/passwd || exit 1
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# Permissions, and current users and groups
sudo -u cassowary $exa $testcases/permissions -lghR 2>&1 | diff -q - $results/permissions_sudo || exit 1
$exa $testcases/permissions -lghR 2>&1 | diff -q - $results/permissions || exit 1
Only highlight escaped characters in file names Rather than the *entire* file name. The current method is extremely inefficient, but having control characters in file names is also extremely uncommon; it’s something that should be fixed, only eventually.
2017-05-01 14:06:37 +00:00
# File names
Also escape characters in links and headings Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module. This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
2017-05-01 20:54:53 +00:00
# (Mostly escaping control characters in file names)
Only highlight escaped characters in file names Rather than the *entire* file name. The current method is extremely inefficient, but having control characters in file names is also extremely uncommon; it’s something that should be fixed, only eventually.
2017-05-01 14:06:37 +00:00
COLUMNS=80 $exa $testcases/file-names 2>&1 | diff -q - $results/file_names || exit 1
COLUMNS=80 $exa $testcases/file-names -x 2>&1 | diff -q - $results/file_names_x || exit 1
Also escape characters in links and headings Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module. This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
2017-05-01 20:54:53 +00:00
COLUMNS=80 $exa $testcases/file-names -R 2>&1 | diff -q - $results/file_names_R || exit 1
Only highlight escaped characters in file names Rather than the *entire* file name. The current method is extremely inefficient, but having control characters in file names is also extremely uncommon; it’s something that should be fixed, only eventually.
2017-05-01 14:06:37 +00:00
$exa $testcases/file-names -1 2>&1 | diff -q - $results/file_names_1 || exit 1
Also escape characters in links and headings Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module. This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
2017-05-01 20:54:53 +00:00
$exa $testcases/file-names -T 2>&1 | diff -q - $results/file_names_T || exit 1
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
# File types
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
$exa $testcases/file-names-exts -1 2>&1 | diff -q - $results/file-names-exts || exit 1
Tests for classify and special file types
2017-04-29 08:21:31 +00:00
$exa $testcases/specials -l 2>&1 | diff -q - $results/specials || exit 1
$exa $testcases/specials -F -l 2>&1 | diff -q - $results/specials_F || exit 1
Write some file-type integration tests
2016-10-29 18:25:07 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
Basic glob ignoring See #97 and recently #130 too. This allows the user to pass in options such as "--ignore '*.pyc'" to not list any files ending in '.pyc' in the output. It uses the Rust glob crate and currently does a simple split on pipe, without any escaping, so it’s not really *complete*, but is at least something.
2016-10-30 14:43:33 +00:00
# Ignores
Rename file-types tests to file-names-exts This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
2017-04-28 19:07:31 +00:00
$exa $testcases/file-names-exts/music.* -I "*.ogg" -1 2>&1 | diff -q - $results/ignores_ogg || exit 1
$exa $testcases/file-names-exts/music.* -I "*.ogg|*.mp3" -1 2>&1 | diff -q - $results/empty || exit 1
Basic glob ignoring See #97 and recently #130 too. This allows the user to pass in options such as "--ignore '*.pyc'" to not list any files ending in '.pyc' in the output. It uses the Rust glob crate and currently does a simple split on pipe, without any escaping, so it’s not really *complete*, but is at least something.
2016-10-30 14:43:33 +00:00
Add some symlink testcases
2016-10-29 18:58:34 +00:00
Tests for the directory path fix
2017-04-29 09:56:17 +00:00
# Paths and directories
# These directories are created in the VM user’s home directory (the default
# location) when a Cargo build is done.
(cd; $exa -1d target target/debug target/debug/build | diff -q - $results/dir_paths) || exit 1
Further tests for printing out directory names ., .., and / always seem to cause problems.
2017-04-29 10:52:44 +00:00
$exa -1d . .. / | diff -q - $results/dirs || exit 1
Tests for the directory path fix
2017-04-29 09:56:17 +00:00
Protect xtests against different default users The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one. So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on. Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
2017-04-28 18:34:23 +00:00
# Links
COLUMNS=80 $exa $testcases/links 2>&1 | diff -q - $results/links || exit 1
$exa $testcases/links -1 2>&1 | diff -q - $results/links_1 || exit 1
$exa $testcases/links -T 2>&1 | diff -q - $results/links_T || exit 1
$exa /proc/1/root -T 2>&1 | diff -q - $results/proc_1_root || exit 1
Properly handle errors when following a symlink Fixes #123. The code assumes that every File that has its link_target() method called would first have been checked to make sure it’s actually a link first. Unfortunately it also assumed that the only thing that can go wrong while following a link is if the file wasn’t a link, meaning it crashes when given a link it doesn’t have permission to follow. This makes the file_target() method able to return either a file or path for displaying, as before, but also an IO error for when things go wrong.
2016-10-29 19:27:23 +00:00
Replace the testcases script with a Vagrant VM See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
2016-10-07 18:31:03 +00:00
echo "All the tests passed!"
Reference in New Issue Copy Permalink