Thread (13 messages) 13 messages, 3 authors, 2016-06-15

Re: [PATCH v4 7/7] t/README: Document the do's and don'ts of tests

flat view

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:49:05

Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted hunk ↗ jump to hunk
+Do's, don'ts & things to keep in mind
+-------------------------------------
+
+Here's a few examples of things you probably should and shouldn't do
+when writing tests.
"Here are" perhaps?
quoted hunk ↗ jump to hunk
+Do:
+
+ - Put as much code as possible inside test_expect_success and other
+   assertions.
+
+   Even code that isn't a test per se, but merely some setup code
+   should be inside a test assertion if at all possible. Test scripts
+   should only have trivial code outside of their assertions.
Let's make it even stronger; "should only have trivial" -> "shouldn't have
any ... unless there is a good reason."
quoted hunk ↗ jump to hunk
+Don't:
+
+ - exit() within a <script> part.
+
+   The harness will catch this as a programming error of the test.
+   Use test_done instead if you need to stop the tests early (see
+   "Skipping tests" below).
+
+ - Break the TAP output
+
+   The raw output from your test might be interpreted by a TAP
+   harness. You usually don't have to worry about that. TAP harnesses
I'd recommend dropping "You usually...about that"  You do care, but the
limitation may be not so severe.
quoted hunk ↗ jump to hunk
+   will ignore everything they don't know about, but don't step on
+   their toes in these areas:
+
+   - Don't print lines like "$x..$y" where $x and $y are integers.
+
+   - Don't print lines that begin with "ok" or "not ok".
+
+   A TAP harness expect a line that begins with either "ok" and "not
+   ok" to signal a test passed or failed (and our harness already
+   produces such lines), so your script shouldn't emit such lines to
+   their output.
+
+   You can glean some further possible issues from the TAP grammar
+   (see http://search.cpan.org/perldoc?TAP::Parser::Grammar#TAP_Grammar)
+   but the best indication is to just run the tests with prove(1),
+   it'll complain if anything is amiss.
+
+Keep in mind:
+
+ - That what you print to stderr and stdout is usually ignored
+
+   Inside <script> part, the standard output and standard error
Splitting the above into two sentences (or a header and a body) makes it
unclear that your "usually" comes from the earlier "Do Put as much code
inside test_expect_success...".  I think you can simply drop "That what
you print ... ignored".

Everything else in the series looked good.  Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help