You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having now gone through the process of writing a test, I'll echo a comment from Harry in one of the earlier meetings: using a test client and validation with more structured input/output that's aware of protocol details (e.g. Golang's HTTP library) would simplify test writing, insofar as it provides stricter checks on that input and output. With bash+curl validation, I knew what I wanted to write from the outset, but spent a lot of time tracking down issues inherent to those tools, e.g. incorrect variable syntax (missing a $), forgetting argument syntax (I knew which curl flag I wanted to use, but forgot the exact argument format, and curl's own graceful degradation made this difficult to discover--it still made a request, but not the request I wanted), or including extra characters that didn't break the script entirely, but made it test the wrong things (I left an extra parenthese somewhere that appended it to command output, breaking the string comparison the test relied on). Having something like Go's compile/vet checks avoids that class of mistake, or at least separates reports of those mistakes from the actual test run.
The rationale behind writing test cases in Bash in the first place was because it was the quickest for me to get up and running. There's nothing preventing us from rewriting those in a more suitable language if need be.
The text was updated successfully, but these errors were encountered:
per #869 (review)
The rationale behind writing test cases in Bash in the first place was because it was the quickest for me to get up and running. There's nothing preventing us from rewriting those in a more suitable language if need be.
The text was updated successfully, but these errors were encountered: