Loading ...
Sorry, an error occurred while loading the content.

Re: [PATCH] Invalid closing parenthesis in test62.in

Expand Messages
  • ZyX
    To prevent the issues tests that can be placed into sourced .vim files and wrapped in :try should be wrapped unless they are testing the errors themselves. I
    Message 1 of 5 , Jul 14, 2013
    • 0 Attachment
      To prevent the issues tests that can be placed into sourced .vim files and wrapped in :try should be wrapped unless they are testing the errors themselves. I also completely do not understand why all tests have to be invoked by the weird and recursive construct from `dotest.in`, with “manual” quit in each test which makes forcing vim not quit require at least two actions:

      1. Commenting out explicit quit statement found in each test.
      2. Adding `call getchar()` to prevent problems with recursion.

      . They also each use Xdotest and test.out file which prevents them from being launched in parallel. There is also non-test test1 which does some setup for other tests, it should be a .vim file launched from makefile and definitely not test1 “test”.

      The whole sequence to run test:

      1. open testN.in
      2. run dotest.in
      3. define a (recursive!) mapping there
      4. from the mapping write (part!) of the opened file to Xdotest
      5. from the mapping source newly written Xdotest as if it was typed text
      6. in the sourced file append to the testN.in
      7. write part of testN.in to test.out
      8. quit with explicit command in Xdotest
      9. compare written test.out and copy it to a separate (now test-specific) location in case of failure

      sounds like a Rube Goldberg machine for me. Why recursive mapping if no recursion is possible with 8.? Why risking accidental overwrite of test*.in file? Such errors are not fatal with mercurial, but still inconvenient. Why indirect sourcing and another file if you can use comments for the header and footer (these parts are excluded at point 4.)? Why copying to a separate location in 9. if you can write there from the very beginning?

      And also very “interesting” test49 with errors like “(402653184 instead of 134217728)” and no easy way to run specific subtest in the debugger.

      There is the way I write tests (using http://vimpluginloader.hg.sourceforge.net/hgweb/vimpluginloader/dev-tools/file/f6fc000e885edccec0afd93bede5b1704e93c4f8/test.zsh):

      0. No tests are dependent on each other. When running more then one test in parallel there is no other option as you can’t say whichever will run first; and test.zsh runs like this by default.
      1. All tests are copied into an empty directory under /tmp before proceeding.
      2. Features required for specific tests are described in a separate (and less verbose) file, you don’t have to write `if !has('python') | e! test.ok | wq! test.out | endif`.
      3. Test output is written in files with filenames unique to each test.
      4. `test*.in` are passed to -s directly, without using some weird recursive mappings and :source!. If one needs any he can add this in test.
      5. `qa!` is added to `test*.in` at point 1. It is not added if it was requested not to add quits thus you can easily use environment of the failing test without any trickery with commenting out anything.
      6. Because of 3. I can run tests in parallel using screen. I can even use wine to test on windows if I need.

      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    Your message has been successfully submitted and would be delivered to recipients shortly.