Llewellyn
/
exa
mirror of https://github.com/Llewellynvdm/exa.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
exa/xtests/run.sh

33 lines
806 B
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
Use Specsheet for the extended tests This commit changes the way the extended test suite is run. Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems: • It stops at the first failure, so if one test fails, you have no idea how many actually failed. • It also didn't actually show you the diff if one was different, it just checked it. • It combined stdout and stderr, and didn't test the exit status of exa. • All the output file names were just whatever I felt like calling the file at the time. • There is no way to only run a few of the tests — you have to run the whole thing each time. • There's no feel-good overall view where you see how many tests are passing. I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time. The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files. So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 19:39:44 +00:00
trap 'exit' ERR
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
Use Specsheet for the extended tests This commit changes the way the extended test suite is run. Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems: • It stops at the first failure, so if one test fails, you have no idea how many actually failed. • It also didn't actually show you the diff if one was different, it just checked it. • It combined stdout and stderr, and didn't test the exit status of exa. • All the output file names were just whatever I felt like calling the file at the time. • There is no way to only run a few of the tests — you have to run the whole thing each time. • There's no feel-good overall view where you see how many tests are passing. I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time. The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files. So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 19:39:44 +00:00
# Check for release mode
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
case "$1" in
Move the packaging script into its own file Having it all echo-ed into the file like that made it hard to read *and* hard to maintain. My initial aversion to it was that I didn’t want there to be an executable script in the main repository that only worked when you were in the VM, because people would just run it anyway. But this can be avoided by leaving it non-executable, and having a command in the VM that runs it instead.
2017-10-01 07:48:20 +00:00
"--release") exa_binary="$HOME/target/release/exa" ;;
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
*) exa_binary="$HOME/target/debug/exa" ;;
esac
Tests for disabling colours
2017-06-25 10:53:59 +00:00
Justfile improvements
2021-04-01 08:39:03 +00:00
if [ ! -e /vagrant ]; then
echo "The extended tests must be run on the Vagrant machine."
exit 1
fi
Fail xtests fast if the exa binary doesn’t exist
2017-08-19 22:27:26 +00:00
if [ ! -f "$exa_binary" ]; then
echo "exa binary ($exa_binary) does not exist"
Formalise exa-packaging script Every time I had to build exa, I copied the files manually and checked to make sure they all had the same name. There’s now a script that does all that stuff for me, so I don’t need to remember to do it anymore. It also does some things that weren’t being done before, including stripping the binary and listing its linked dependencies to we can tell if something like libhttp_parser has slipped in there (see #194)
2017-08-20 17:19:58 +00:00
if [ "$1" != "--release" ]; then echo -e "create it first with \033[1;32mbuild-exa\033[0m or \033[1;32mb\033[0m"; fi
Fail xtests fast if the exa binary doesn’t exist
2017-08-19 22:27:26 +00:00
exit 1
fi
Use Specsheet for the extended tests This commit changes the way the extended test suite is run. Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems: • It stops at the first failure, so if one test fails, you have no idea how many actually failed. • It also didn't actually show you the diff if one was different, it just checked it. • It combined stdout and stderr, and didn't test the exit status of exa. • All the output file names were just whatever I felt like calling the file at the time. • There is no way to only run a few of the tests — you have to run the whole thing each time. • There's no feel-good overall view where you see how many tests are passing. I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time. The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files. So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 19:39:44 +00:00
echo -e "#!/bin/sh\nexec $exa_binary --colour=always \"\$@\"" > /tmp/exa
chmod +x /tmp/exa
export PATH="/tmp:$PATH"
Fail xtests fast if the exa binary doesn’t exist
2017-08-19 22:27:26 +00:00
Use Specsheet for the extended tests This commit changes the way the extended test suite is run. Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems: • It stops at the first failure, so if one test fails, you have no idea how many actually failed. • It also didn't actually show you the diff if one was different, it just checked it. • It combined stdout and stderr, and didn't test the exit status of exa. • All the output file names were just whatever I felt like calling the file at the time. • There is no way to only run a few of the tests — you have to run the whole thing each time. • There's no feel-good overall view where you see how many tests are passing. I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time. The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files. So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 19:39:44 +00:00
# Unset any environment variables
export EXA_STRICT=""
Test for debug mode
2017-08-19 12:57:56 +00:00
export EXA_DEBUG=""
Add exa_colors to make exa themable This adds support for the EXA_COLORS environment variable, and defines a bunch of exa-specific two-letter codes that I pretty much made up arbitrarily that control parts of the interface. Fixes #160, which I didn’t expect to actually fix this release cycle, but it unexpectedly became easy to do!
2017-08-26 22:17:07 +00:00
export LS_COLORS=""
export EXA_COLORS=""
Use Specsheet for the extended tests This commit changes the way the extended test suite is run. Previously, there was a folder full of outputs, and a script that ran exa repeatedly to check the outputs match. This script was hacked-together, with many problems: • It stops at the first failure, so if one test fails, you have no idea how many actually failed. • It also didn't actually show you the diff if one was different, it just checked it. • It combined stdout and stderr, and didn't test the exit status of exa. • All the output file names were just whatever I felt like calling the file at the time. • There is no way to only run a few of the tests — you have to run the whole thing each time. • There's no feel-good overall view where you see how many tests are passing. I started writing Specsheet to solve this problem (amongst other problems), and now, three and a half years later, it's finally ready for prime time. The tests are now defined as data rather than as a script. The outputs have a consistent naming convention (directory_flags.ansitxt), and they check stdout, stderr, and exit status separately. Specsheet also lets simple outputs (empty, non-empty, or one-line error messages) can be written inline rather than needing to be in files. So even though this pretty much runs the same tests as the run.sh script did, the tests are now more organised, making it easy to see where tests are missing and functionality is not being tested.
2020-10-17 19:39:44 +00:00
# Run the tests
exec specsheet $(dirname "$0")/*.toml -O cmd.shell=bash