Jason Franklin wrote:
> I'm writing two new tests for a patch that fixes a bug with the
> ":close" command. There is already a file for testing the various
> commands that close a buffer/window (see
> "src/testdir/test_winbuf_close.vim").
>
> My questions are:
>
> Should new tests always be placed in their own file to isolate their
> environment?
Only when needed. E.g. when it depends on no command history. It is
quite uncommon. If there is interference you would usually notice when
running the test (unless something is skipped for your setup).
> Are tests in the same file run in the same Vim process? Can I override
> this?
Not easily, and there usually is no point in doing so. It is useful if
you want to run Vim with specific arguments or context. For normal
tests it's easier to create another test.
> When is it okay to keep tests in the same file? When is it not okay?
> Is there a general rule to follow?
Usually it's fine. Just make sure you cleanup at the end of the test
function.
--
MORTICIAN: Bring out your dead!
[clang]
Bring out your dead!
[clang]
Bring out your dead!
CUSTOMER: Here's one -- nine pence.
DEAD PERSON: I'm not dead!
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
