-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add test harness using ts #3
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
# ignore test artifacts | ||
/tmp |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
# Shared test setup goes here... | ||
|
||
# Mock this out so the harness can be demonstrated | ||
core_init_defines () { | ||
true | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
#!/bin/bash | ||
|
||
# | ||
# Run like: | ||
# | ||
# ./test/suite | ||
# | ||
# To run individual tests, run the test file: | ||
# | ||
# ./test/variable/variable.test.functions | ||
# | ||
# Use `-v` to see stderr on failing tests. Use the test name to run just one test. | ||
# | ||
# ./test/variable/variable.test.functions -v test_core_variable_startsWith | ||
# | ||
|
||
find . -type f -name '*.test.*' | | ||
grep -v -E '(helper|suite)' | | ||
xargs ts "$@" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This script should change to use the _program wrappers - see the overdrive tutorial - to make it robust on all platforms and helpful, too. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,63 @@ | ||
#!/bin/bash | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. #!/usr/bin/env sh There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I test There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep. And it works better on platforms like debian, where /bin/sh => /bin/dash ... |
||
. test/helper | ||
. variable/variable.functions | ||
|
||
setup () { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Our code style is:- setup()
{
logic
} Using tabs not spaces (unlike my example). |
||
true # replace as needed | ||
} | ||
|
||
teardown () { | ||
true # replace as needed | ||
} | ||
|
||
# | ||
# Example testing with assert_status - good for multipart tests because | ||
# you can add a comment and go off of various exit statuses | ||
# | ||
|
||
test_core_variable_startsWith () { | ||
core_variable_startsWith "/etc/path/to/file" "/home/" | ||
assert_status 1 $? "variable does not start with prefix" | ||
|
||
core_variable_startsWith "/etc/path/to/file" "/etc/" | ||
assert_status 0 $? "variable does start with prefix" | ||
} | ||
|
||
# | ||
# Examples testing with assert_output - simply makes sure stdout is the same. | ||
# Stderr is not checked but you can of course use redirections. Not good for | ||
# multipart testing (see the docs, it's because of the pipelines) but in | ||
# truth I use these more than I use assert_status. | ||
# | ||
|
||
test_core_variable_firstCharacter() | ||
{ | ||
core_variable_firstCharacter "abc" | assert_output "a" | ||
} | ||
|
||
test_core_variable_lastCharacter() | ||
{ | ||
core_variable_lastCharacter "abc" | assert_output "c" | ||
} | ||
|
||
# | ||
# The other useful thing ts provides is $ts_test_dir - the path to a test- | ||
# specific directory where you can make files, nearby where some ts-related | ||
# files are placed in `./tmp`. The files are left after tests complete so you | ||
# can inspect them, but cleaned up prior to each run. I don't see a function | ||
# in this module that could use it rationally, but to illustrate... | ||
# | ||
|
||
test_core_variable_trimWhitespace () { | ||
mkdir -p "$ts_test_dir" | ||
file_with_whitespace="$ts_test_dir/file" | ||
cat > "$file_with_whitespace" <<DOC | ||
|
||
some text | ||
|
||
DOC | ||
|
||
core_variable_trimWhitespace "$(cat "$file_with_whitespace")" | assert_output "some text" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we do assertions without a pipe? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep. The tests succeed if they return 0 and fail otherwise. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. cool. So could we invert the logic, and have test_assert_output "some text" core_variable_trimWhitespace "$(cat "$file_with_whitespace")" Much neater and no sub shell. |
||
} | ||
|
||
. ts | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need to control folder / path locations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use #!/usr/bin/env sh for shellfire scripts so that we don't force a particular shell on folks.